On Fri, Mar 21, 2008 at 2:27 PM, Steve Sanbeg <ssanbeg(a)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?