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.