HTML/CSS Template files for Hijack's HTTP streamng

I wrote mark a message about this last night. He asked me to start a discussion in here. So here we are.

I was asking about the possibility to support some type of template format to allow us to create or own HTML layout for his generated HTTP file streaming pages.

It's best to get input from people with experience in this sort of thing to make sure to get a solution that is both as simple as possible for people to manage/modify as well as something as elegant and versatile as possible for Mark to implement.

So, who can help get some ideas ironed out so Mark can see what he has to work with? I'll avoid mentioning any specifics so this thread doesn't prematurely get shifted in a certain direction. I'm sure you guys will have a few different ideas and it would be nice to get to see them all.

Bruno

one idea that Edna uses is to use XML as the template. I'm not sure if this is something that can be done in kernel or not (haven't even looked at XML processing) but it worked pretty well.

This exact thought had crossed my mind too but I didn't want to hassle Mark any more than necessary seeing as the page(s) generated are perfectly functional as they are. So do you want ppl to submit some prettier design ideas in HTML format?

The idea is that Mark should not have to stuff any specific HTML layout into his kernel. This would get to be insane as people would have their own preferences, and Mark would need to keep maintaining, or at least hearing about, this and that suggestion to modify the look this and that way.

What this thread should focus on, is the method by which a template structure or method could/should be implemented. Mark mentioned that someone had also brought up the use of CSS.

With some type of template, Hijack could load the default page on the drive and just send it variables. What we need is a specification for the template structure/format.

I haven't sat down to think about this enough, plus I don't have the most experience working with dynamic content to be able to make a very specific suggestion.

I'd be happy to have Hijack pull the template in multiple parts if need be to simplify structure as well. Ideally it would be nice to not waste much code space in the kernel. Hopefully Mark will chime in here with some ideas for what he considers easy parameters to pass and how.

Bruno

Well, I may be wrong but wouldn't XSLT be ideal for this? If Hijack squirted out the XML data for the playlists and transformed it using a user designed XSLT template then dished out the resulting HTML to the user's browser this would do wouldn't it? I know that this relies on the user being proficient in XSLT but maybe we could write an application which creates the XSLT file automatically from some user specified settings. Just an idea. What do you think?

That might do the trick, but unfortunately I don't have any XML experience to be able to say. One of the primary reasons I started the thread to get ideas from everyone. So, more opinions?

In the end, I think that any soultion would be best served with the ability to use common tools to modify the stored template. Something which would allow some visual feedback to the creator would be nice - but I suppose it could always involve sending to the player for preview purposes.

I'm already imagining some of the things I'd like to do (I'm a very visual person). I could easily create my look in plain HTML and CSS (with my own bitmap graphics as well), but that isn't a solution for this problem.

Bruno

That would mean that either Mark would have to write an XML/XSLT parser in the kernel, or call a third party XSLT parser. Neither of these are really practical to do from the kernel. Writing your own XML/XSLT parsers is a distinctly non-trivial task.

If you want to have some sort of templated HTML in the kernel for the playlists then the format is going to have to be fairly simple to make it easy to parse.

I agree with Andy here, kernel memory and other resources [Marks Time] are in short enough supply now without trying to burden it with a XML parser.

I think the best approach is a KISS one - lets go with the simplest approach that does the job.

Even CSS might be overkill for this application.

My suggestion would be to use a template with some sort of variables in it, Mark then substitutes the right variable in the (template designers) indicated spot and when its done, outputs the whole html page.

Right now the current html streaming stuff is pretty good - yes it could be make to look nicer but the basics work so all we need to do is extend this area enough so that we can personalise this a bit and thats all.

I'd be fine with keeping it to HTML. Now, how to structure the template so it can be made to use whatever Mark thinks is a good idea to output?

Bruno

I have a simple template based system I wrote for use at work.
Basically it consists of a header, footer and a line which is repeated for each row in a database. (I actually store them as three separate fields in a template database.. you might have to store them as three separate files, perhaps filename.head, .foot and .rep ?)

In my code, I can do a simple string replace for a set of known tags (for example with hijack you could have tags like @title@, @artist@ etc...)

The header and footer can be used for table setup code as well as the page "branding".
It works quite well for me... =)

If you were to use HTML / XML style tags <mp3title> <artist> <album> then unrecognized tags wouldn't cause a problem with the output.

Just a few thoughts...

That's how I was thinking it could be implemented from the begining. I just wasn't sure about how to get substitutions for what Hijack would pass.

In my personal implementation, I'd like to be able to repeat more than one row. To allow for alternate row colouring. I'm assuming Hijack would need to support this in its implementation. Or you'r probably be left with two rows with the exact same song data, etc...

This sounds like something very straight forward to edit and maintain though. Also should be versatile enough for most people to create a very personalized and compelling play page.

Bruno

Actually, I don't see how he would have to write or incorporate any parser at all.

It's funny, I had written Mark an email about this a couple of days ago too, and orginally came down on the html template side, using some kind of token system to identify where the variables should be added to the html. But if we're really looking for flexibility, xml is the way to go. That will totally abstract the data from the presentation, which might be good for some other future applications. Perhaps you'd have an application (not a browser) that would want access to that playlist / tune data, but you don't want to have to wade through the html. XML would be the way to go.

The reason I don't think Mark would need to write or incorporate a parser is that all he'd be doing is writting an output stream, just like he is with the html. He didn't write an html parser, did he? If the code on the empeg simply enclosed the data in xml tags, and it was well-formed, we could take it from there. Even the people that don't know XSLT very well could easily be able to change a simple stylesheet to include what they wanted. The XML / XSLT parser lives on the client in this case. The server (the empeg) doesn't need to "process" the XML at all. It doesn't need to query, or store, or present the data, it just writes it out. The browser (or any other application) will do that work.

Let me know if you think I'm off base here, but again, I don't see any reason not to spit out xml.

I wanted to get this out there first. In my next post, I'll show an example xml and an example XSLT stylesheet to process it so everyone can see how easy this is.

Chris

As I understand it people were asking for the HTML template to be applied on the empeg side, which is why I said that having the XSLT transforms occur in the kernel was unworkable.

It is obviously a different issue if the XSLT parsing is happening on the client. That then of course introduces new problems of making the client side stuff work on different browsers/platforms, which is why I think people were asking for a simple server side template system.

Anyway, if people want to transform the data on the client then Mark only needs to make a small change to the current HTML (adding missing quotes around the "border" attribute on the "table" tag) to make it valid XML.

it wouldn't be too hard to write up a spec for a simple template structure. The problem with using XML or any other already existing template structure, is that they are complex and not suitable for a small-memory footprint implementation. For this, you need something that lets you define variable substitutions, and simple looping accross different items. I've done some of this stuff before for various dynamic HTML content projects I've worked on.

Some limitations need to be figured out to define what the environment each page would have. Basicly, I'm figureing that each page would be about a single playlist, and therefore there would be global playlist tags (%title%, %source% etc..) as well as tags for each item in the playlist. You would definately need an iterator function to have sections of code/variables repeated for each item in the playlist. During that iteration you would need to have a couple conditional statements to allow you to create HTML that doesn't provide links that you don't want. For example, a conditional statement for if the item in the playlist is annother playlist. so a %playlist(<code if true>) and %notplaylist(<code if not>) might be doable. It's easy to want to write a script language or some other complex template language, but I think we need to get some guidance by Mark as to what is easiest and doable in kernel..

Using the above commands, I'll write up a simple template to explain what I'm getting at.

I actually do alternating colours in my implementation, although it's handled in a slightly different way.
You'd need some way to define something like colour1, colour2, bgcolor1, bgcolour2 maxcolours=2 in an options file, and then hijack could use a simple counting property to switch the colours for each line (you would use something like <tr bgcolor=@colour@> in your filename.rep line file)

The options file could also be used to associate different filename.head etc files depending on which pages are being shown (assuming that other types of pages appear in the future... =)

So far this is the idea I canmost easily wrap my mind around.

Of course I'm interested in seeing some of those XML examples mentioned above. For some reason, this thread is making me think of "Iron Chef" - "over here the Iron Chef is is using XML and custom parser... The challenger is sticking to tradition! Look at the creative use of the table tag."

Bruno

quick and dirty mockup from the code that's currently generated by hijack:

substitutions

	%<field>%



conditionals:

	@iffield:<field>:<code>@

	@ifplaylist:<code>@

	@notplaylist:<code>@



iteration:

	@iterate:<code>@



---Begin---

<HTML><HEAD><TITLE>%title%@iffield:artist:- %artist%@</TITLE></HEAD>

<BODY>

<H2>%title%@iffield:artist:- %artist%@</H2><TABLE BORDER=2><THEAD>

<HTML><BODY><TABLE BORDER=2><THEAD>

<TR><TD> <TD> <b>Title</b> <TD> <b>Length</b> <TD> <b>Type</b> <TD> <b>Artist</b> <TD> <b>Source</b> <TBODY>

@iterate:<TR><TD> <A HREF="%fid%?.m3u"><em>Play</em></A> <TD> <A HREF="%fid%?.html">%title%</A> <TD> %length% 

<TD> @ifplaylist:playlist@@notplaylist:tune@ <TD> %artist% <TD> %source%@

</TABLE></BODY></HTML>

---End---

Edit: chopped a line in half to reduce the width of the post..

If you wanted to grab the XML off the empeg, and combine it with XSLT etc on another machine then hijack could be modified to add an xml output via fid?.xml in the same way that html is output via ?.html
The template file ideas are to keep processing to a minimum on the empeg.

Right. I guess I was assuming that everyone is running an XML/XSLT capable browser, thus the processing would be done on the client. Is that not the case? We have any IE / Netscape 2.0 users out there? That's one of the benefits of the xml / xslt model, less processing on the server, move the presentation to the client.

Well, maybe we could cajole Mark to do the html template and the xml...hummmm

Mark, when are you going to setup a Paypal account? :-)

Anyway, I'll get my examples up asap. It'll be interesting to see if people's browsers can process it.

-c

Actually, I was checking out the source html, and it's not really that close to valid xml. Most of the table tags aren't closed either. thead, tbody, td, tr. That is as of v160 anyway.

You are right, I didn't look hard enough at the HTML.

Yes, but in my experience the XML/XSLT handling of different browsers is varied enough to make such an approach a challenge to get working with different browsers/parsers/platforms.

I agree, however it would be a nice to have if hijack could output a XML formatted file of the current playlist(s)/tunes - simply add a different file type following the ? in the URL e.g. instead of ?.html use ?.xml and (once support is there) - Marks Kernel can output a simple [but Valid] XML file instead of the HTML he does now.
The XML contains the same info, except its XML not html.

If folks want to do clever stuff Client-side then they can - use the XML request and resultant file, rather than the .html request.

That way we obviate the need to have a full XML parser in the hijack kernel while still giving client-side folks who do want XML a quick and relatively easy fix.

I am sure Mark can output a simple XML file for most of the playlists/tunelists instead of the HTML he does now without much code change.

I think if I had a XML stream of playlist/tune info then I for one would be able to do the client side in Windows/IE, so could others.
Other platforms client-side issues would have to be handled by others who are working on these platforms.

However this would be a 85% or better solution I think.

For what it's worth, I'd like to see the processing moved client side as well. Whether it's HTML with CSS or XML with XSLT, client side will be a heck of a lot more flexible in the long run.


Even if some basic server side template ability shows up, we should definitely still have the ability to have Hijack serve an XML stream with an tag declaring the appropriate XSLT sheet. Barring that, it should have a way to specify a CSS in the HTML output. The appropriate XSLT/CSS can be hosted on the empeg so that the client can fetch it when referenced and do it's processing.

-Aaron

Okay, here are two sample files. One xml and one xslt. I've tested this in IE 5.01 SP2 (Win2k), and IE6 (Win2k). It should (theoretically) work on any IE 5.0+ browser. I haven't (and can't / won't) test on any other browser. I'd be very interested to hear if it does / does not work in any other modern browser. Let's say, a version that's been released in the last 3 years.

The XSLT spec used here is the "working draft" version, so, it's not the XSLT 1.0 spec. If I used the 1.0 XSLT spec, fewer browsers would support it. You'd have to make sure you had (if using MS) MSXML 3.0 running in replace mode (or running IE6).

Just place both of these files in the same directory, and open the xml file in your browser, and it should look exactly as it would appear in Hijack (as of v167).

I made the xml a shortened version of my actual empeg-car playlist. I put a couple of loose tracks in there, just to show how it would be handled. Now that this is done, you should be able to see how it would be very easy to change.

Also, other advantages of using XML would be the easy client-side sorting and filtering capabilities. This might be very useful if / when we get to "see" the soup lists. We'd also have to expose more info from the *1 files, such as genre

Comments and questions appreciated.

Chris

P.S. No making fun of my music, I have eclectic tastes.

Looks good - works fine on my Win XP system with IE6 [as expected].

Yes I concur that this looks like a way forward. The XML file could contain all the info in the *1 file, as the xslt could then only output in the html, the fields actually needed.

I am steering clear of this discussion, since I know nothing about CSS or XML right now. Just let me know what you folks decide -- give it a couple of days to soak, and then appoint a messenger to email me.

For what it's worth, I like the concept of having a "?.whatever" tag to have Hijack just return the tag file contents (all tags, not the just few it uses today) in whatever format is decided upon.

Cheers

This illustrates my point exactly. Even just these two simple files do not work on a recent build of Mozilla under Windows, which probably means they do not work on Netscape 6 either.

Anyway, this shouldn't stop us from asking Mark to provide XML output, as it should be straight forward for him to do.

Hey,

I just wanted to chime in and say that the XML/XSLT file works great on Windows 98/IE5.5. Mozilla (2/1/02 nightly build) doesn't konw what to do with the XML file though.

later,
ajay

Yes, what I think we need to do is this.

0. Agree that a XML file is the best way forward as a alternative method of outputting the playlist infomation currently available from the hijack kernel. I don't think we will hear too many objections to XML from Mark as its so much like what he's doing now with HTML and is the most 'platform' and implementation independant way of making this info available.

1. Decide amoungst ourselves what this XML output should look like, bearing in mind that Mark has said he wants to implement what we decide, but he does like the ?.xml idea to request xml output [assuming we agree on this point].
We need to bear in mind that the XML file will contain both [by design], both tunes and playlists - and should show the order in which the tunes and playlists should be mixed [relatively easy to do given that all tunes are in a playlist, and the playlist could itself contain playlists].

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.
I think that the request for a XML playlist could include a second parameter [like ?.xml&xslt=.... ] which could contain a URL encoded XSLT file location. Mark Lord's XML generation routine will then embed this second parameter as a reference in the output XML file it spits back.
Its important that the Client gets to indicate the XSLT file location as it could be a file local to the client, or the empeg itself or somewhere on the internet - the client will know this and Mark shouldn't need to care - he just echoes it back in the right place in the XML

However, the issue then arises about what if we should want a 'default' XSLT file stored on the empeg itself and a reference to it is delivered in the XML file if no XSLT is requested in the .xml request.

In this case I think we need to be able to have a 'default' xslt file 'location' in config.ini - and Mark can embed this location reference in the XML file even if we don't ask for it.
This has a benefit that a simple xml request will come back, [with possibly a xslt file reference in it, if a default xslt file location is defined in config.ini] and the client then either ignore the xslt reference in the XML file, or process the xml using that xslt reference.

3. Any implementation should be designed with compliance to the w3C standard in this area [for XSLT references and XML format] and structure (e.g. XML elements versus attrributes), but needs to be aware that not all XML implementations [read few], actually work with the W3C standards now but obviously when they are made compliant they will to the W3C standards.
So some kind of 'compatibility' mode needs to be considered for (to use a MS term) "downlevel browsers/client".

Once we have agreed on how much of the above we want, we need to then write it all up nicely and give it to Mark for him to implement when he gets time.

And then we need everyone who wants these features to help us all test the implementation on their platforms and OS's and clients.

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().

> 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].