On Thu, Jul 17, 2003 at 12:06:12PM -0400, Christopher Curtis wrote: > 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. Another downside: needing a special tool to manipulate it. Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to extract out the good layers, or do a lot of work by hand to figure out how to use dd to grab it. With say ar, the user can extract individual layers by some tag, referenced in the xml metadata. Then can edit the xml to stub out the broken layer, and repack it and have a valid xcf file. This could be the difference between losing 10% of the work vs. all of it. So while a user can open a text file header in an editor, they are going to need a tool anyway to manipulate it effectively. That's the advantage of using a standard format. Using standard tools to manipulate it. More likelihood of a machine having a tool installed, and less work for the GIMP team in maintaining special tools. You're right about simplicity though, and ar is simpler than tar or zip/jar, which is why I prefer it. zip/jar is especially crappy since the file index is at the end, which means it's harder to recover from a partial file. There's also no reason the GIMP can't have a native ar parser to load and map in a file directly without unpacking it somewhere on disk. -Yosh
