On Fri, 21 Mar 2008 11:16:14 -0400, Simetrical wrote:
On Thu, Mar 20, 2008 at 11:07 PM, DanTMan dan_the_man@telus.net wrote:
The difference between doing it in PHP and XML, is that using the XML setup, we can read in that data without requiring that any of that data be included or anything (ie: For extensions that are not installed)
What do you mean by "included" in this context? It would not be difficult, if desired, to have separate files to load info and to load the extension itself, or to use some kind of switch to achieve the same effects.
XML:
- Moderately easy to write by hand
- Moderately easy and fast for most modern computer languages to read
and manipulate. Can typically be read in and manipulated with a relatively simple (but not necessarily well-known) set of functions. Parsed forms can be cached in memory data stores, but extra manual checks are needed to make sure the files have not changed.
PHP:
- Very easy to write by hand (fewer delimiters, less redundancy, etc.)
- Incredibly easy and extremely fast for PHP to read and manipulate.
Loading and parsing takes basically no time at all with opcode cache, which every installation that's serious about performance has. Functions to manipulate data structures are extremely familiar, fast, and powerful because they're just regular PHP data structures. Opcode caches will automatically cache the files and maintain integrity with stat()s, but those can be easy avoided by a one-line config change if you use a script like scap that can purge the opcode cache.
- Something of a pain for other languages to read and manipulate.
Possible if it's really necessary, but slow and error-prone. Will need custom functions.
Given that MediaWiki is written in PHP, I don't see any reason to care about other languages. As a data storage format, PHP files seem to be much better than XML files in every way for our purposes.
Is performance much of a consideration here? I'd expect a few short files, parsed infrequently.
XML:
*easy to convert to wiki markup, to include in documentation. *would force a consistent interface if this interface allows editing config settings, which I'd hope it would.
PHP:
* A simpler API; each extension could have an arbitrary configuration callback, and a test method, which would allow the installer to grey out & display a status message for unusable extensions.