Hey thats good news crocklobster.

My input to all this is that you should output as much info as you can to allow both versions in the same XML file. You may care to structure the XML file so that level 1 consumers can easily locate the stuff they need while level 2 consumers can get at the raw data easily as well, rather than mixing it all up it might be easier to have 2 sub-nodes in the XML tree for each song - 1 with all the level 1 stuff in it, the other with the level 2 (i.e. raw) data.

The level 1 consumers (those browsers not capable of doing their own math) should have the same (or more) XML fields available to them for their playlists than they get now in raw html.

Level 2 consumers (those that can do their own math) can manufacture what they need from the base data, and can then crib whatever data is also available in the file for the level 1 consumers - (this should include the fids for song and tag files as well as whatever information we have available from the database file).

The reason for including the fids/drive # of fids etc is that with this sort of information we can construct a full path to the tag or song itself and if needed actually open and extract additional (non-XML) data at the client-side if needed to provide additional enhanced playlist functionality.

I am not sure how much work is required of Hijack to implement the first solution [to support downlevel browsers]. But once its done it would be useful to still output the info for more advanced consumers.

In general I would expect any XML file to output as much information as it has available (and can make available fairly easily) from day 1 - the resultant XML file will not be large enough that including everything will slow things down and it will ensure that the potential users of this file are larger than if we do a cut down version and then extend it.

Thats my input.