httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lee Fisher <>
Subject Re: data
Date Mon, 11 Jul 2011 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 

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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message