Henrique de Moraes Holschuh wrote: > The snippets would need to be all read, and XSLT-processed in the user's > system, every time an entry is updated. Which only occurs when packages are installed, updated, or removed, right? Even on unstable machines (aside from package developers), that's usually no more than once per day. > Isn't this going to be way slower and memory hungry than a simple parser? Well, it should be way more flexible, and way easier for new developers to learn, since it will be based on industry standard tools rather than some homebrew parser/translator. Whether it's actually all that much slower or memory-piggy is hard to say. XML parsing isn't really that complicated; most of the difficulty is in dealing with different character sets, doing validation with DTDs or schemas, external elements, and so on. If you skip all that by standardizing on a single character set (say, UTF-8) and letting your application-level code decide whether the document is valid, it becomes quite simple. The XML language to describe a menu system shouldn't be terribly complex, so validating a pile of small documents (I'm assuming one menu file per package, like the current system) against a simple DTD, and then translating them into another format, shouldn't be too expensive. I've been doing a lot of work lately with XML and XSLT, and I haven't found xsltproc to be a performance problem at all. Though in the interest of full disclosure, I should admit that I haven't run it on anything slower than a 700 MHz Celeron with 384MB RAM. Craig
Attachment:
pgpp529d8Jdbi.pgp
Description: PGP signature