In reply to:


Without an xslt file, the xml would not be very useful to a browser. It would be fine for some other application that did it's own xml parsing and querying, but a plain xml file would have no "a" links to navigate the playlists. So, at least for a browser, an xslt file would be pretty much required.



Agreed, however the reason why we are doing is this is not simply to support nice looking html playlists (although thats a definite benefit/outcome of this concept), its to allow the useful Playlist Information to be made available to the widest range of applications, platforms and operating systems in the easiest to produce and easiest to consume ways possible.
XML is the best way forward for this without a doubt.

However, right now the HTML output is ok, its usable, but is not easy to customise, and in all likelihood the easiest way to customise the playlist is on the client rather than rely on Mark to put even more code and stuff into the Kernel - remember the kernel and everthing attached to it is a finite resource.

In truth a lot of stuff Mark's put in the kernel [like the http server] would in a normal system be a 'userland' application (as most http servers are). Mark put it there (in the kernel) as it makes the deployment a real cinch at the cost of some Flash RAM and memory overhead when the kernel is running (which may well be less than if a bunch of Userland apps were all running in the same memory space).

If someone can suggest a real easy way that allows Mark to do customised html playlists server side that doesn't require lots of custom files and CGI-type scripts then lets hear it. But I've yet to see a concrete suggestion for this using server-side html processing that will suit everybody and their platforms - and in there may never be one right way.
(e.g. Not all browsers support CSS to the same level).

I freely admit that the XML/XSLT idea is not without its drawbacks - the biggest issues are variable levels of implementation/conformance on the client(s) everyone uses.

MS & IE6 seems to offer the best right now, but thats not the most suitable for everyone. Other browsers like Mozilla and Netscape etc will offer W3C standard support sometime in the [hopefuly, near] future.

But XML is definitely the way forward for everyone longer term.

In the interim, then we have these options:

1. Those who want nice CSS playlists etc, can do so using the XML file output from the proposed XML: support feature in Hijack. But they require a seperate webserver/process that can take the XML (or HTML) sent by Hijack and then munge it into the nice CSS html version that they want - they have that problem right now even without XML support. But XML support will make the whole thing a lot easier.

i.e. use a local Linux box to act as a 'front-end' to your Empeg for custom playlists etc.

While this sort of thing would be nice done on the empeg itself rather than needing a seperate box. But the reality of 12-16MB of RAM on the Empeg/RioCar and the software in it is currently optimised to play music not act as a generic web server means it may be best kept away from the empeg itself.

2. Upgrade to a W3C XML/XSLT compliant browser (when available) and use the integrated XSLT support in that to do the nice playlists. (preferred option for everybody)

3. Create a custom application [ala emplode, probably in Java ] that will let you interract with the empeg playlists and will do the CSS/HTML etc 'on the fly' for you using the XML and/or HTML output from the Hijack kernel. This is like Option 1 but not necessarily done on a web server.

I think Option 2 is the way forward, options 3 & 1 can provide some customisation without requiring lots of Hijack kernel resources.

It may even be that someone can implement option 1 on the empeg itself, as a Userland app [making requests the Marks http server running on a different port from the normal/standard port of 80].

In reply to:


I don't have any problems with an "&xslt=" parameter, but I know that I would only use a file local to the empeg, and wouldn't want to change files during the browsing of a playlist. If you did, you could actually make an xslt file request a different xslt file for certain playlists, but changing the "a" tag for that playlist.

When this might be cool is if we had a repository of xslt files on the web somewhere and everyone could very easily see what other people have done, and whether they work on their platform. That would be cool. A "default" stylesheet is definitely a good idea. It'd be best if we didn't have to specify a parameter, if we wanted to use a default stylesheet. Especially now that there is the http://your.empeg/?playlists alias.

One thing about a client choosing or not choosing to process the stylesheet... I'm not sure how you would do this. That I know of, there is no way to tell IE not to process a stylesheet if there is a stylesheet reference in it. If there was a stylesheet reference, it requests the stylesheet and processes the output. Note that if the stylesheet doesn't exist where the reference says it does, you get an error in IE. Again, in other, non-browser client applications, you could definitely choose whether to process the stylesheet.



The best way not to make the browser use the xlst file, is not to include a reference to it in the xml file. Hence the idea of the &xslt parameter to the Playlist request URL.

The &xslt parameter idea lets us [the client] define the XSLT file we want to work with when we receive the XML file back from Hijack. If we leave the xslt parameter off we get the default [if its defined, otherwise we get no xslt reference in the XML]], if we provide this parameter but its empty, we also don't get any xslt reference either in the XML.

This lets the client decide (up front) whether it wants the XSLT reference in the XML or not - if not, its a boring regular XML file, otherwise if the XML parser is aware of XSLT, then the transform using the XSLT is done, then and there on the client as the XML is received from Hijack.

With a optional xslt reference in the xml file we can have the best of all worlds.
We can request one if we know there is one available,we can specifiy 'playlist specific' xslts if we want, we can even use other peoples xslt files - if we know where they are stored. But the Client does all this, not the Hijack kernel - all it does is serve up regular XML playlist files as its asked to.

We can produce publish and share our 'playlist' xslt scripts - theres perhaps only a few dozen on this BBS that write xslt scripts right now, but in the same way not everyone here is hacking the empeg kernel - most people leverage off others work - the same goes for XSLTs.
But there could be some really neat XSLT's created that will do really amazing things - then we can all use this without needing a new hijack kernel every time we add some new platforms to the client list.

I imagine that if this is implemented then Riocar.org will have a section where we publish our XSLT files we want others to be able to use - they can either make one of them the default XSLT on their system [by setting it so in config.ini], the actual XSLT file may live on the empeg , it may live at RioCar.org or it may be somewhere else [your local machines hard disk].

The point is that you only pass a reference to the file, and not the file itself.
[the parsing/using the file is done by the webbrowser or application consuming the XML - if its xslt aware, if its not, then you have a regular XML file].

For clients with no concept of XML then its either simple HTML or whatever else they support.