On Fri, Mar 21, 2008 at 2:27 PM, Steve Sanbeg ssanbeg@ask.com wrote:
Is performance much of a consideration here? I'd expect a few short files, parsed infrequently.
Every extension must be loaded (at least partially) on every page view. Making ten extra calls to memcached is probably going to add a millisecond, although less if you retrieve them all at once (which memcached supports AFAIK). So not the end of the world. Having to actually parse the XML would be slower.
Overall this will probably not be a bottleneck or a major consideration, though, you're right. Simplicity and ease of use are more important, in PHP's favor. Frankly I don't know PHP's XML API.
Actually, come to think of it, since when do we require any kind of PHP support for XML? We have our own XML function library. I haven't seen us use built-in functions. I think I've seen us optionally use them for SVG validation, but IIRC it skips that part if they don't exist. Does this really not require an extra PHP module dependency?
XML:
*easy to convert to wiki markup, to include in documentation.
No harder than PHP. We convert PHP documentation for extensions to wikitext already, on Special:Version, although that's fairly minimal as documentation goes. What were you thinking would be the advantage here, in a little more detail?
*would force a consistent interface if this interface allows editing config settings, which I'd hope it would.
It seems to me we were talking about info files, not anything that users would be expected to edit. We do dynamically generate some PHP files (well, at least one: LocalSettings.php) with no problems. What do you mean by a consistent interface? Could you expand on this?