11 Jul 2011 21:05
Re: modules.apache.org data
Lee Fisher <blibbet <at> gmail.com>
2011-07-11 19:05:05 GMT
2011-07-11 19:05:05 GMT
> In my ideal world, we'd want something that the module authors > can update themselves, and doesn't require a lot of maintenance > on our end. Having something where they host some kind of data > file on their end that we retrieve periodically seems good to > me, but I don't know the details of making that happen. Having > a database thingy that they update on our end seems fine, too. If I can ignore the password fields, and the login history table, and can manage to convert the Php/MySQL numeric date to a human-readable XML date, then the work I've been doing in XML is usable. If the login history and password fields need to be used in the resulting system, I think I have to drop this XML work, and go back to getting the Php/MySQL running as a new system. A new system might be able to use the email fields to reset things, and ask for a new password. If solution is wiki-based, it seems likey they'd have to create a new account on the wiki, and might be ok if we don't have to translate the old accounts (and passwords) over to new wiki accounts. So, besides password field issue, and data field conversion, I can continue to normalize the XML of the base data. But if login history or passwords need to be carried forward, I should start over and figure out how to rebuild the old Php/MySql web app, so 100% of it's tables can be migrated forward. Is there any high-level Apache DOAP, FOAF policy that would help decide the proper direction w/r/t hosted XML metadata? If a DOAP file approach is used, shouldn't these DOAP files be distributed with the module source, and thus probably be hosted in Svn, or generated when generating a build? PS: The current module data has a variety of data normalization issues that need addressing. There are multiple broken email addresses, some null, some " at " and " dot " notation. There are multiple empty and broken URLs. Some HTML markup is included in the SQL string fields. Some records include multiple URLs (one for the .c module source, one for home page, and since there's only 1 URL field they overload the title or description field. Some unnecessary newlines, trailing and leading whitespace are in many fields. And there's a few int'l names that will need robust character set support in final system.