Re: Itunes structure (off-topic)
Re: Itunes structure (off-topic)
- Subject: Re: Itunes structure (off-topic)
- From: Bob Ippolito <email@hidden>
- Date: Tue, 6 Apr 2004 10:48:21 -0400
On Apr 6, 2004, at 9:47 AM, Reed Hedges wrote:
On Monday, April 5, 2004, at 07:40 PM, Allan Odgaard wrote:
and by keeping your data as xml you do not place yourself in a
situation where you can't change it in the future, heck you may even
write your own (faster) xml parser which does the same as
"dictionaryWithContentsOfFile:" if it turns out to be a problem.
Colleagues of mine have had good results replacing a full XML parser
with a custom Bison parser, if the XML vocabulary is not huge and
well-known. This of course defeats part of the point of XML but we
saw some great speed increases. (This was for RPC messages that were
almost nearly valid XML; each message was pretty small and the
vocabulary is fairly simple-- it basically boils down to
<(message|update) ...attribs...> <field
...attribs...>...cdata...</field> ... </(message|update)>).
Flash (SWF), GIF and ID3 (v2.x) are all horrible formats in this
regard, apart from the first two being little endian, then they all
have various bits which decide the length of other fields, wether or
not some fields are present and so on
[off-topic, missing the original poster by a level]
Flash is the most obscene file format still in use today, as it
actually has various BITS (as in, not multiples of 8 bits) that decide
the BIT length of other fields, which isn't really even little endian.
It seems that not everyone at Macromedia rides the short bus though:
the Flash IDE spits out files that are mostly byte-aligned and they
surely have fast-paths for those cases in the player, and they have
been using zlib for compression since Flash v5 -- which is a much
better and more sane way of making small files.
GIF is a perfectly fine format, it is actually MUCH MUCH easier to
write a binary parser for the GIF header in a low level language than
it would be to decode some XML garbage, especially in the 1980s when
well, XML DIDN'T EXIST AND NO PARSERS WERE AVAILABLE FOR IT!
As for ID3 v2.x, I see no real good reason to store XML at the
beginning or end of all your mp3 files. I don't know the specifics,
but they might be trying to encode it into valid MPEG frames, which are
pretty small, so XML would be a bad idea there too.
In any case, you are an idiot if you write your own library for dealing
with ID3 and GIF for nearly anything but educational reasons, and you
have very little reason to complain about the formats.
A good compromise is to replicate the idea of XML in a terser
so-called "binary" format, using type and length prefixing. E.g.
define byte values that indicate "start of tag" (append
length-prefixed name of tag in ascii) "end of most recently open
tag", "start of cdata", "start of attribute" (append length-prefixed
name of attribute), "start of attribute value", (append
length-prefixed value)
or something like that.
That is essentially what the "real" iTunes database is, except it uses
four character codes to represent type information (unsurprising
similar to AppleEvents, QuickTime, etc.) and has no "end of tag"
identifiers. The start of a collection tag marks how many 'things' are
in that collection and how big the entire collection is in bytes.
-bob
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.