Ya, the extension data files only need to be loaded on the special pages
where they are needed. ie: Extension lists, and installation/management
of them.
The only thing we need to know on every page view, is if an extension is
installed or not. And obviously that would be done using a schematically
cleanly written, auto-generated PHP file which the manager would make
modifications to.
You could also offer use of memcached for it, for those who will
complain "You must be file-system independent!!!"... However, I'd just
screw anyone with that viewpoint, cause this is a complete bonus
feature, and the filesystem already needs to be web writable to setup
the extensions in the first place.
You don't need to add a PHP dependency to do XML. I looked at this all
awhile back. And there is actually a very nice PHP XPATH project. It
works on PHP 4 & 5, and has no extra library dependencies. So it could
simply be included in MediaWiki and used to read out data from XML files.
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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l