Re: Itunes structure (off-topic)
Re: Itunes structure (off-topic)
- Subject: Re: Itunes structure (off-topic)
- From: Reed Hedges <email@hidden>
- Date: Tue, 06 Apr 2004 09:47:39 -0400
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
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.
reed
_______________________________________________
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.