A couple of comments:

In reply to:

---

2. Address the issue of a [optional] xslt file to allow some browsers to format/process the XML as HTML or whatever the XSLT does [automatically], on the Client-Side.

---

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.

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.

I may try this in Mozilla. I'm suprised it doesn't work. They've either dropped support for the draft spec of XSLT, or they don't handle xml, which would be really suprising.

If I find something out / make it work. I'll post the results.

Chris

P.S. Last comment: Go Pats!

Humm, really thought I posted this before, but it never showed up. Maybe I didn't hit that last Continue.

I checked out the Mozilla website. Apparently, they offer no legacy support of the XSLT working draft spec. As IE5/5.5 came out before the spec was finalized, their support is the working draft spec. IE6 supports both.

How to change the stylesheet to the 1.0 XSLT spec.

Change the XSLT namespace attribute value from:
http://www.w3.org/TR/WD-xsl to:
http://www.w3.org/1999/XSL/Transform

Also, a version attribute must be added to the xsl:stylsheet tag. So, right after the XSLT namespace, put version="1.0". That should do it. I haven't actually tested this in Mozilla, but I did test in in IE6, and it should work the same, as they both go to the 1.0 XSLT spec.

Let me know what you find.

Chris

Can we just make sure that in the end, when all is said and done, we will still have a way for people like me, who don't want to undertake learning XML right now, to be able to create or modify these templates to suit our needs?

I'm fine if the more xml-centric stuff can be abstracted and I'm left with the ability to just style the page with some rather plain html.

My initial thoughts were of simplicity for Mark as well as for anyone wanting to customize. Don't want to lose sight of that even though we're going forward with "cool stuff"(tm) that can serve a much larger future purpose.

Bruno

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.

I think this is getting overly complex for little reason.

In reality, the point of this thread WAS to get custom HTML playlists up. Not to allow for a communication platform to the kitchen sink.

The subject says quite clearly TEMPLATE and FILES. That means that none of the "look" goes into Hijack, regardless of how this ends up being implemented.

This thread is also not about creating a need for custom applications (VNC, etc.) This is about putting one or a few files on the empeg disks that anyone with a browser can point to. ANY browser. What we need is the method to get the data to the template. If someone has a very capable and NEW browser, then they are free to make a really fancy template that uses crazy amounts of CSS and javascript or whatever they want. If someone else has a simple browser, they're free to make something simple (as long as they still have the minimum capability to take the data and put it into the template file).

Jazzwire had the idea which fit the closest to the spirit of this thread. And if the data can be easily tweaked to slightly different formats, then the suggestion of having "?whatever" would still allow for both XML as well as HTML.

There are far more people using Hijack than contribute to threads about Hijack. And there are far more people using it than know how to implement an XSLT file.

Anyway, back to the confusion.

Bruno

Well if you think Jazzwire is the kind of idea that you think is closest to what you want to achieve, then how about explaining how it works here for all folks to read.

I've never heard of Jazzwire - maybe its the greatest thing since sliced bread, maybe not.

However if we expect Mark Lord to implement it then we need a clear and concise statement of what you want to achieve and how you expect someone to implement it in the Hijack kernel.

Then if we agree, I say go for it.

Like I said others raised XML and client-side support as no-one here has actually clearly explained yet how the server side implementation will actually work in a platform neutral way and how easy it will be for others to customise.

I don't expect a miracle, but I expect a clear precis of Jazzwire posted here if thats the suggested 'closest match'.

Jazzwire is a PERSON. I think you (anyone who's intereste in this topic who hasn't already done so) go back to the very first post of the thread, IN FLAT MODE, and read each and evey post.

Anyway, reading my original post will give you an idea of what was being proposed. You should also re-read your original post on the subject which proposed keeping things simple. That much I agree with.

Bruno

As a programmer, I don't mind figuring out XSLT/XML/HTML/or any other ML we decide on. XML/XSLT is a nice idea for data transmission, but in this application, it seems like the browser support just isn't there. As Mark uses a Linux box, I wouldn't expect him to put a lot of time into something that he wouldn't be able to use. There are tradeoffs for any system, and they're all different in this case.. HTML temlates require more processing, but are %100 supported in browser (as each person can customize the template for whatever platforms they want.. javascript/CSS/etc would be all custom). XML/XSLT are faster, as the kernel just needs to generate of the XML, while the browser does the template work..

Yes, I misunderstood who Jazzwire was.

I did read Jazzwires original post when it was made - which I agreed with it as an idea, but the point I'd make is that each template is made up of 3 files in his scenario [or 3 logical parts of a single file].
1 For the header, 1 for the 'body' ( the repeated bit for evey tune/playlist) and then 1 for the footer

So thats 3 files/sections to be managed on the Empeg - no problem, except we have to agree what goes in the file in terms of content, special tokens to act as placeholders and styling etc, it also assumes that this structure is enough for our needs - on the surface, yes it does sound ok & we have to have some way to get those files to the empeg in the right place and manage them somehow [as presumably they are not edited on the empeg itself]. And all of that is do-able.

Then you immediately said (more or less) 'but I'd want every other line implemented in alternating colour in my version" ala the Emplode listview.

So suddenly the original implementation needs to be extended to handle odd/even lines in different colours.

No problem there either, except Mark Lord has to implement it somehow, so do we now implement this using 4 templates/sections - header,footer and Body A, Body B templates?

Then, what if someone says, well I would use this except I want either pair of tunes/playlists to be alternating in colour not just every line, and maybe someone else wants to have all Playlists in a different colour from Tunes (more likely given that Playlist contain tunes it useful to show them in a different colour again from odd/even lines in the body).

So, the feature set grows and grows - all of which we expect Mark Lord to put into the Kernel and support - yes we maintain the file contents but the file parser and serialiser to produce the HTML on the fly has to be written by Mark and extended as our needs extend.

And thats before we have even dealt with Platform/Browser/CSS whatever implementation issues for HTML to be emitted.

FWIW: The above feature set of header/footer, alternating body line colours and tunes and playlist in different colours in the table is what I could live with in a template solution.

But its not the full answer to customising the playlists.


Which is why I suggested we apply a simple(r) solution - output a XML file of ALL the information in the *1 files (or the Database), in a structured way that fully describes the current playlist - then let the consumer of the XML choose what format to render it into - HTML for you/your web browser, CSV for someone else, XYZ format for someone else (and what data to show, and what to suppress etc)

Mark could produce a XML version of the playlist pretty easily I would think - provided he had a XML structure to follow that allowed for both Playlist and tunes (and for the nesting of these).

The issue with this is then - where is the XML that is emitted, actually consumed/processed?

Given that a full XML parser implementation on the Empeg would take quite some some resources [e.g. someones time to port a XML parser from elsewhere and the memory usage when its running], it has been suggested [by others as well as me], that we off-load this processing to the Client application who requests the XML data in the first place rather than have the Hijack kernel have to do it.

Since XML also allows us to specify a XSLT tranformation that we want to apply to the XML, we can also have the rendering from XML into HTML suitable for a browser to work with, done on-the-fly by the client, provided we put a reference to the XSLT file in the XML file we produce and that have a web browser thats up to date enough to be able to transform the XML file using the XSLT reference in the XML.

As a nice simple to have extension then we also would like to be able to tell the Hijack Kernel where the XSLT that we want to process the XML with is located - and we provide that on the URL we give to the Hijack http server when we request the XML playlist in the first place - this lets us all share our xslt files that render html versions of our playlists so that others can use it.

Thats it. I think thats pretty simple. The only issues with this approach are:

1. What should the XML file look like? - so Mark can program it.

2. Who will write the XSLT's for the various platforms/browsers out there that support XSLTs in XML?

While I have no simple answer for 2, there are lots of people around this BBS now who can write XLST's well enough to do whats required to produce pretty sophisticated html pages from the XML, theres even some offering to do it now in this very thread. I'm putting my money where my mouth is - I'll produce & publish a XSLT of the playlist that will work in W3C compliant parser as well.

I'm not knocking Jazzwires idea, or yours, I merely caution everyone that we can only avoid lots of trips to and fro to Mark to get this, or that feature added if we do it the right way to start and have a clear idea that the template idea is a reasonably short term workaround/quickfix and no more.

So to move forward - I suggest that we ask Mark to start with a simple template file(s) idea and have the XML export implemented soon after. This will allow a customisable playlist in HTML for those of us who want nice(r) semi-customisable playlist in their browsers now, with the more flexible (fully customisable) XML feature useful for the really advanced stuff and modern web browsers that can support XML into HTML on the fly.

I'll let you guys come up with the Template solution that fits your needs.

If anyone wants to contribute to the designing of the XML file then let me know/start another thread or whatever - once we have a XML file layout, we can then give it to Mark and let him program it, then we can document how the file works, produce some XSLT's that work with it and then put it up on RioCar.org or whereever.

In reply to:

---

Since XML also allows us to specify a XSLT tranformation that we want to apply to the XML, we can also have the rendering from XML into HTML suitable for a browser to work with, done on-the-fly by the client, provided we put a reference to the XSLT file in the XML file we produce and that have a web browser thats up to date enough to be able to transform the XML file using the XSLT reference in the XML.

---

number6, I think this is where everyone else is getting lost. The XML stuff is just data. The XSLT tells the browser how to view the data.

If you don't get it, take a look at crocklobster's post earlier in this thread with the attached xml/xslt files. Throw both of those files in notepad and you'll see that the 101.xml file is just a list of a few tracks wrapped in some basic tags. And at the top it points to listEntries.xsl. The XSLT file is similar to Jazzwire's template design except it's a little more confusing. But all the HTML is there and it's pretty easy to understand and edit. The best part is that the XSLT file doesn't have to be HTML, it can be anything, like a CSV or ABC, etc... However you want to represent the playlist data in the future, then just provide a proper XSLT file and you're done. This is much cleaner then asking Mark to add different handlers for everything we want supported.

As far as what the final XML file should look like, I think a good start is the XML that is output from a shoutcast server. It has a lot of good information about the current status of the server plus recently played songs and some other info which is nice. I'd like to see as much info as possible in an XML file that I can parse from somewhere else. I dunno, it'd be cool to plug in my empeg on the network and have a cheesy PHP script (on another webserver obviously) grab the XML file and update a webpage with stats from the empeg.

I know, that last part is well beyond the basic template plan. But the XML/XSLT method isn't as compilcated as you might think. An XSLT file is just a template file for the XML data.

later,
ajay

In reply to:

---

Change the XSLT namespace attribute value from:
http://www.w3.org/TR/WD-xsl to:
http://www.w3.org/1999/XSL/Transform

Also, a version attribute must be added to the xsl:stylsheet tag. So, right after the XSLT namespace, put version="1.0". That should do it. I haven't actually tested this in Mozilla, but I did test in in IE6, and it should work the same, as they both go to the 1.0 XSLT spec.

---

I tried this tonight and it fixed Mozilla, but broke IE 5.5 which sucks. There has to be something that will work in both. Actually, we can just probably create two XSLT files and reference them depending on which browser is requesting the XML file. Just a though...

later,
ajay(wondering how many more posts until I'm not a 'stranger' anymore)

In reply to:

---

Actually, we can just probably create two XSLT files and reference them depending on which browser is requesting the XML file.

---

Yeah, that's the beauty of picking a sheet via something like the ?XSLT= request in the URL. Everyone can use whatever XSLT they want to make sure that it works through whatever broken, non-standards compliant browser they happen to use.

Yeah, sorry if I wasn't clear enough on this.

If a browser supports only the XSLT 1.0 spec, you have to use the 1999/XSL/Transform namespace and the version number. If your browser does not support the 1.0 spec, you'll have to use the TR/WD-xsl spec and the version is optional.

Browser / ver-------Spec supported
IE 5&5.5--------------Working draft only
IE6--------------------Working draft and 1.0
Mozilla---------------1.0 only

What is the typical browser used in Linux? Can someone test that this works? I don't think it's true that browser support isn't there. I've only seen one person say it didn't work in Mozilla, but then I found and posted the fix.

I'd also disagree that it's too complex for people to be able to edit. If one can understand HTML, one can understand XML / XSLT. At least the basic stuff that would be used to process this data. Also, if you didn't want to even look at xml, you could still always bite other people's stuff and probably be very happy.

Also, I don't think we should trash this idea based on the subject line of the thread. Wouldn't it be a good thing for it to be easily ported to other applications and work equally well on browsers?

It looks like we definitely want to have xml access, so I'll put something together as an empeg-bbs RFC. It'll specify how the calls would be made and a possible structure of the xml. Remember, that the real structure hardly matters, as the xslt would be able to interpret it however it was built. There are, of course, "better" ways to structure as compared to others.

It also appears clear that others don't want to (or have to) use the xml / xslt model and still want to customize the html. I leave it to someone else to come up with a possible spec for that.

Chris

Just a little suggestion; Couldn't we use the same XML structure as that which can be exported from Emplode? I think this would make most sense. Forgive me if I've missed something crucial and I'm talking out of my backside.

Thanks for pointing that out. The XML file matches the database very closely, which will help in reverse engineering the database format.

Actually... thinking about it, is there any way that we could use the XML exported by Emplode for this? Or would it be more hassle than it's worth? I'm thinking that you could export XML from Emplode then upload it onto the player somewhere. I know it would contain data for all playlists & tunes so you'd have to do some kind of filtering on it to create a page at the correct level in your hierarchy but it might be quicker than Hijack having to create the XML on the fly. I know this would be no good for those who don't use Emplode though. Unless the facility is added to the other tool(s) such as JEmplode. Just another idea for the pot. Discard it if it's crap.

I was thinking about that as well, however it wouldn't contain the latest information about the files. Such as the last-played date, skip counts and such. I don't know if it is a big loss, but it's something..

I had the same clear mind while writing displayserver. I chose to use javascript. The cgi-part just streams out javascript arrays, which get prepended to an HTML-file. Use a loop in javascript to create tables and you're finished.

Did you ever figure out the database file format, or did you just use the raw tags/playlists from the fids directory?

-ml

I did figure out the database format. It's mostly the same as all other empeg files, like the font files. I think I've got some piece of code which reads it. As you've noticed, it's been a while since I last posted and coded stuff on the empeg, so give me some time to find it. Damn you are fast...

It comes down to this :
alot of FF's in the fron which should be skipped ( I think )
then one byte with tag info. I think I read the mapping of tag-numbers to names in the emptool source. the next byte indicates the length of the data. After that the data is presented.byte FF indicates end of record. If you look in the emptool source you'll also find different types of fids, of which some of them are also in the database.

I've got a lot of expereince with XML and XSLT and there's one thing I can say for sure: XSLT is slow, and it'd be even slower on a 200MHz processor. Also it's a lot of work to write an XML and XSLT processor so what I propose is that the kernel can either output HTML in the form it is now, or XML using ?.xml as the extension.

XML files can contain a PI (processing Instruction) that tells the parser ( in this case the browser) what XSLT file to use to transform the document.

This way we can use the existing HTML code that Mark has written, and just add some XML support and then we can write the XSLT ourselves and not burden Mark with it.

All of the processing would be done on the client machine so the empeg unit only has to dish out 2 files (+ any images and linked docs)

Just my 2 cents.

-B

I suppose the tag-info byte might correspond to a line index into the /empeg/var/tags file.. ?

Mozilla is _really_ picky about XSLT stylesheets. It won't transform XML unless the stylesheet comes down as text/xsl

If you want to see an example of the javascript thing, connect to [ur]lhttp://empeg.dyndns.org:81[/url]. I've routed port 81 to my empeg with ds2 on it. In netscape you've got to save the file to disk before you see the javascript. view source shows the generated source.

Yeah, I'm sure what you say is correct. You undoubtedly have more experience with this than I do. I did start to learn XML & XSLT for a project I was going to be involved in with a friend but nothing ever came of it. Consequently I am familiar with the concepts but don't have the practical experience needed to judge which is the best way to implement it all and where the processing should be done. I just like to throw some ideas into the mix and let better equipped people sort out the best methods to use.

That's funny. I just tried the applet and your hijack-suite, but the applet keeps showing the song info while operating the menu...

The tags file contains the attribute list. At the start of a record there's also a fid-type if I can remember right..

Frank,

How cool would it be to get your java applet working with Hijack? I think very cool. I even tried to do it myself. Alas, I'm a Java neophite. I actually got the image refreshing, but it was a very slow refresh. Still it's a lot better than a refresh tag on a frame to keep opening the empeg_display.png.

Chris

Guys, the database format is documented (kinda) in lib/protocol/protocolclient.cpp. Look at ProtocolClient::RetrieveDatabases().