DragonFly kernel List (threaded) for 2003-10
Re: Xml in packaging system
That's exactly my point. Since xml is still ascii, you can always use
vi to fix things when they are really screwed. But it still gives you
many of the benefits of a more complicated binary data format. I think
this is important for something like a package system when potentially
many tools (written by many different people) are munging your package data.
And if it grows really large, you can always use Sleepycat's xml database.
And in my experience, whenever a project uses name=value pairs, the
"value" part becomes increasingly complicated until it starts to look
like a pseudo-html or pseudo-xml.
But anything would be better than the format used by INDEX.
Starting a new project is very different
from maintaining or enhancing an existing
In the xml vs all other options debate
the advantages of choosing xml will
occurr when the inevitable updates and
upgrades occur. It will be easier to
enhance xml based data formats without
breaking existing code.
Take pretty printing, or importing
exporting the files to other programs.
If you choose xml as the underlying
format these types of operations are
xml is the new ascii.