> Guys, the database format is documented (kinda) in lib/protocol/protocolclient.cpp.

Aww.. that takes all the fun out of it..

Theres one (two word) good reason why you want a 'on the fly' XML file created based on the current playlist.

"Wendy Filters"

Which if you recall are a way of dynamically changing what songs show up in your playlist at any given time.
Since these are applied while in the car, any 'canned XML' playlist info will therefore contain songs that may not be played in the current playlist.

I agree with everything you just said.

Lets do XML and see how it flies.

The only Comment I'd make, is do we wait for the structure of the database file on the empeg to be documented (and read) or do we simply go with whats in the *1 files as a first cut.

I think *1 files is simple, bvut has a real performance penalty in that Mark Lord has to open and read every *1 file to produce the output.
the database idea has merit, but we need to have some working code that can work with this file first so that Mark can use it instead of (or as well as) the *1 files.

I will be interested in the proposed XML RFC when you release it [either draft or final].