On Fri, 21 Mar 2008 14:44:10 -0400, Simetrical wrote:
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.
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.