On Fri, 21 Mar 2008 14:44:10 -0400, Simetrical wrote:
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.
I was assuming this would only be used by a restricted special page to enable/configure available extensions, and that installed extensions would otherwise be the same as they are.
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?
I haven't seen fully compliant (i.e. to the point of marking CDATA) XML, although I haven't really looked for it. I guess that's mostly significant if we want to be able to include arbitrary code (i.e. a test function) and still have these be parseable outside of mediawiki.
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?
It seems like some of the proposed fields replicate what's already in the on-wiki documentation. So it might be nice if there was a bot that could comb through all the info files on the CVS, run them through an XSL transform, and convert them into infoboxes to keep the docs up to date. Of course, it should be possible to something similar by getting the relevant parts from a PHP format.
*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?
Say we have a special page that lists extensions, with an enable/disable and configure option, and that the configuration options are somehow encoded in the file. It could be an XML schema to represent them, so that the extension manager could generate a preferences form, then generate the extensions settings from that; or the extension manager use a callback from the extension to get a form, and let the extension take care of the details.
That's not to say that I have a strong feeling one way or the other, but rather that flexibility for things like these are probably a better deciding factor than raw performance in this case.