[in the future, please send replies to the mailing list as well]
On Fri, 12 Dec 2003, Devin Bayer wrote:
> I would prefer the package format, a lot like the way OpenOffice.org
> settles the same problem. The main reason is the easy manipulation of
> the images. If they are base-64 encoded within XML it's rather
> inconvenient to open them up in Gimp or the like.
This shouldn't be an issue because either way the GUI will have the option
of exporting the image file.
> Also, although .guikachu files will never be too large, putting it in
> a zip archive will not only keep the images from being bloated, but it
> will shrink the XML too.
> And ethically, XML isn't really made for binary data; it just isn't
You're spot on with the file size issue. As for the aesthetics of storing
binary data in XML, I don't like it either, but, surprisingly, the W3C
doesn't seem to have a problem with it, as (as I understand) some of the
more recent W3C specifications do contain binary data in XML.
However, the above are just the direct replies to the points you've risen
-- but there's one more thing that I realized after I sent the question to
the mailinglist, and it is, I think, a big argument in favor of storing
everything inside the XML file: If you look at the Undo/Redo system or the
Cut & Paste code, you can see that it works by storing a single
resource/widget in a single XmlNode. I don't see how this clean and
elegant way of re-using the IO system for undo/redo and c&p could be
modified if the data for one resource is scattered in multiple files.
.--= ULLA! =---------------------. `We are not here to give users what
\ http://cactus.rulez.org \ they want' -- RMS, at GUADEC 2001
`---= cactus@... =---'
Microsoft spel chekar vor sail, worgs grate !!