Sven Neumann wrote:
"Christopher W. Curtis" <ccurtis@xxxxxxxxxxx> writes:
The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional
I don't think the format you proposed is valid XML. There might be XML
Rule #1 in brainstorming: don't criticise any idea, no matter how silly.
parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character.
I would reiterate what I said, but you quoted it. "fully parseable by XML parsers up until the first NULL". I'm not trying to jam image data into an XML format - simply prepending an XML header and using NULL as a separator. This means you can cat the file and know exactly what's there. Or you can open it in notepad (maybe make it NULL, ^Z for Windows people...) "file" will be able to readily identify the individual formats, and people could even use dd to extract the layers.
Is there a special reason you dislike the idea of using an archive instead of a single XML file? I thought we would have been past this point already...
I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. OTOH, any program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If you want something fast, you can leave compression off and modify the data directly on disk without having to unpack/pack, as long as you stay within limits (ie: you can paint on a layer or move the layer around, but not add a new layer or change the bit-depth, and you just have to munmap() that section). This makes it easy to have specialized external tools that manipulate layer data without all the GIMP overhead, easily scriptable, etc...
This would also be a much simpler format, and I like simple.
If you want to talk about downsides, I can think of only one: the first data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere.
Chris
