Not logged in. · Lost password · Register
Forum: Features request RSS
Xml Would Be Amazing...
Page:  1  2  next 
Fraser (Guest) #1
No profile available.
Link to this post

First off, great http server. I really like the way you've put it together.

I'm creating a skin for this designed for PocketPC devices as well as the new html capable mobile phones, such as the Microsoft SmartPhone. There is great potential here for the ultimate remote control.

One thing I am considering is keeping the data transmissions as small as possible. This will make things a lot faster, especially for those like myself who will be connecting to Winamp across the web over GPRS, which is a 2.5 G mobile phone transfer system. It's slightly slower than a 56k modem and you get charged by the meg.

A good way to do this would be to have an XML output from your server. This would be really simple to add, the only updates needing done to the server would be:
[*]The output processing applied to *.html files also gets done on *.xml files
[*]Likewise, *.xml files can also be targets of commands e.g. href="dummy.xml?forward"
[*]Preferably, the tags also don't have the # symbol before them
The third one is because it's not valid XML, but this could be easilly worked around if it's not something that would be possible. The client won't ever see them, so it just means you have to handwrite the files (notepad) at the server end, none of the XML tools would accept it.

Then, I'd create some XML files like: e.g. "songtitle.xml"


In reality, there would be a lot more in each file, e.g. the song title, album name, bitrate etc would all be in the same request.

Now, this is the clever bit. XML combines with XSL to produce webpages. The Pocket Internet Explorer application, like all modern browsers is already capable of doing this. The XSL file is essentially a stylesheet, but it can pull XML data from a web server, parse it and then incorporate it into a website.

This way, the bulk of the HTML and all the images would reside on the client device. This would make things super-fast and very cheap to run in terms of data costs. Obviously those with wireless LAN capable devices won't be as concerned about this, but I'll be using it over GPRS myself.

If this is something you'd be willing to help out on, I would be very grateful!
Guest (Guest) #2
No profile available.
Link to this post
you should try this server here:

it is a xml server plugin for winamp.

it works great but has a few limitations that make it fatally flawed for my purposes:
  • you cannot delete a song from the play list

  • you cannot queue a song to play next: every song you add goes to the end of the play  list.

  Victor will not release the source code so development of the plugin is dead. I played around with a klugy workaround using php. It deletes the play list then reloads a new playlist with the song you want deleted. Not very elegant so it  abandoned that idea.

on a different note i have some ideas on integrating a searchable database into BrowseAmp: I have all my music in a MySql database so it should be pretty easy to integrate a better search function using php and MySql.  Henry has done a great job making BrowseAmp super flexible in terms of customization.


FIX #3
Member since Mar 2003 · 3 posts
Group memberships: Members
Show profile · Link to this post
how would mysql and php make the search faster?
i think the search is fine it shows results like instant for me
the only thing i see adding php and mysql support would do is let u do more in things in flash with browseamp

i got a treo 300 with sprintpcs and it great using it to control browseamp hehe and u got to love the unlimited data
Henry (Administrator) #4
Member since Jan 2003 · 865 posts · Location: Munich Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Thanks for the creative ideas!

I think this would be possible. But as you may have read before, I want to wait until WA 2.90 is out and I have a new API docu.
And of course I want to implement the new template engine which is now running with QCDBrowseAmp. The you would be able to do all the nice thing you want.

Preferably, the tags also don't have the # symbol before them
The # is required for the parser I use. It cannot be changed by now.
Fraser (Guest) #5
No profile available.
Link to this post
In reply to "Guest", I agree on the fatal limitations with the other tool you mention. The "queue next" option in BrowseAmp is great, a really useful facility, sadly missing in Winamp. I'm going to post another feature request relating to this. Didn't want to do two in one day, a bit cheeky!  ;)

In relation to searches taking long, I have the same problem. The music resides on a network share on my Linux box, and there is a lot. Around 50 gig. The searches cannot take place in time before the HTTP request times out on the client. I was just going to omit the search facility for now, but I'm interested in how you got your music into a database. Do you have any useful URLs on this?

Thanks for the positive reply, Henry! The #symbol stuff I figured would be neigh on impossible to change, but I thought I'd chuck it in to test the water on it.  B)

I'm looking forward to see this update. In the time honored tradition of software dev, I am compelled to ask...any idea when it will be available?   ;)  Is WA 2.90 quite a while away?
genekeenan #6
Member since Mar 2003 · 18 posts
Group memberships: Members
Show profile · Link to this post
In reply to what i used to get the music into a database:


There is other open source stuff out there but i liked this one because it uses MySql or Postgres which are both fast for big collections of data like mine:

you will have to install php,mysql and apache


EDIT: Wrong URL, corrected. --Saxtus
This post was edited on 2003-03-29, 02:04 by Unknown user.
FreeJack #7
Member since Mar 2003 · 10 posts · Location: nivaa, denmark
Group memberships: Members
Show profile · Link to this post
Not sure if you can use this, but i've made a skin which returns an xml document. Here's the post.
The problem afaics is that the contenttype is wrong...

This post was edited on 2003-03-28, 15:35 by Unknown user.
Henry (Administrator) #8
Member since Jan 2003 · 865 posts · Location: Munich Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I'm not so familiar with XML so I got some questions about it, just to be sure we talk about the same things.

- I just need a browser like IE, right?
- The document body is stored in an XSL file, right?
- The most difficult work is to create an XSL that pulls data from the server and builds the final doc, right?
- How does the XML browser/parser handle datasets like a playlist?

I hope I'll get some support from you this time.  ;)
Fraser (Guest) #9
No profile available.
Link to this post
OK, no problem.  :)

Firstly, I appologise for the tone here. I write the odd bit of user documentation for the coding I do,  so I tend to break into tech author mode. This might begin to read like a document....  :rolleyes:

The browser does most of the work. Pretty much all of the major browsers support XSL translation, either via their own implementation or the inbuilt microsoft one.

The XSL is basically a script that is parsed to create the HTML. It can include reads to multiple XML files, and do some pretty neat stuff to navigate through the XML data. You're correct in that the tough part is this phase, but I've got no problems with putting it together to parse the data.

There is another topic I've not mentioned...XML schemas. These documents are like roadmaps for the XML files. They completely define the format of the data, what elements can exist below parent elements, data types and so on. XML has built in validation, so if the data is non-conformant, errors can be thrown. However, this processing can be turned off. It's useful though, as it clearly defines the XML interface language that you are creating. This makes life very easy when designing XSL, it's like the API design doc you've always dreamed of. Well, not quite, but it is pretty good!

Playlists could be a sticky one, but nothing to worry about. Best case scenario would be to make available a proper representation of a playlist. This would be by far the best way. An example off the top of my head would be:

    <item position="1">
        <artist>John Lennon</artist>
        blah blah blah
Now this is the clever bit. This is some psudo code to explain how XSL works:
        for-each "playlist/item"
                <TD>value-of "artist"</TD>
                <TD>value-of "track" </TD>
                <TD>value-of "length" </TD>
        /for each

I've left the XSL processing instructions not in tags to make them stand out. When this is applied against the previous playlist, the for-each section is applied to every <item> elements. Note the "playlist/item" selector, it's almost like a file system, navigating through the locations. Each <item> becomes a row in the table.

Some of the more advanced things you can do are creating links. Going back the XML, note the following
<item position="1">

The number here can be extracted easilly, and used in links. So you could call the following URL:


(or whatever your command is, I'm not familiar with that part of BrowseAmp yet)

And have a link to this generated by the XSL with:
<a><attribute href="concat("index.html?play", <xsl:value-of "@item">)">
    play now!

Now, the code above is again not proper syntax, but it's easier to explain this way. You'd put this somewhere in the table row.

To really work with XML and XSL, notepad or vi won't cut it. I've got XMLSpy, which really is the best out there. It does all of the work for you, kind of like a smart code editor with the usual auto-complete etc. You can run debug on your XSL files, steping through them like a normal code debugger, with variable watches as well.

Back to the playlists...the above is best case scenario, but would require some work on your side to get the output format correct. I guess you've done that already, it's no different from the existing code, just the wrapper elements are different (<playlist><item> instead of <table><tr>). I'm not sure how much time you are willing to spare on this.

You could just have the XSL process the HTML that currently comes from the existing playlist function. Just have an playlist.xml file that contained a single tag to the #playlist substitution.
This would make it a lot less elegant and more of a hack. If the HTML isn't W3C compliant (e.g. <p>text</p>), then it won't work either. I've had a brief look at the output as it currently stands, and I can't see any potential problems. It would be ugly, as the XSL would have to traverse <table><tr> all of the time, not very intuative, and losing one of the benefits of XML. The additional stuff, like the stylesheet tags and table information would be a waste of bandwidth though, as it will not be getting used during the XSL processing.

One of the more subtle things about XSL is that it doesn't just produce HTML. Note how my example contained <html><body> elements. You could have XSL producing C++ code if you wanted, just change the wrappers to function calls!  :-D  I've seen someone mention a javascript counter to show track time in another post here...even that could be used with XSL providing a replacement like currentTime=<xsl:value-of "currentTrack/position"> in the javascript.

There is a whole load of potential here, especially by the way you have already got the server running, it's after looking at how the HTML substitution works that I realised it would be easy to do XML as well. The skinner would be able to fully customise the XML output from the server. That is very versitile as you might want to create a cut-down skin that would show the controls and playlist on separate pages, using two different XML output files, one for each. Another skin could combine both into one XML message, again more efficent for that skin.

The post FreeJack referenced was interesting, I can see I'm not alone here  :)  While the HTML table data isn't very XML friendly, this could be tweaked if it was a problem and as I mentioned above, it does look like fairly compliant code. I ran one of the base skin browser.html pages through XMLspy, it didn't like a few comments and other things, but they are from the HTML skin. It had no complaints about the table.

Henry, I noticed your reply to this FreeJack's post, and how you were interested in this concept already, as potential back-end to BrowseAmp. You'd probably want to do things slightly diffently than my idea of processing the XML/XSL on the client. For normal usage where bandwidth isn't an issue, you'd be better off with the server performing the XSL translation. It's pretty easy to do, there are plenty of open source libraries out there for it, I've done it in Java before. My concept of browser-performed translations would still require the browser to get both the XSL and the XML files. I was planning on storing the XSL on the client, which would require some form of required installation. You'd want server-side processing on this stuff for normal web usage. "At the end of the day", the server will still be serving HTML out to the browser.

Cheers! I'm off to rest my weary fingers now!  :)
Henry (Administrator) #10
Member since Jan 2003 · 865 posts · Location: Munich Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Thanks for the short introduction to XML (Yes, I am able to read so many lines)  :) .

Now that I know the most important things I can say that it can be done very easily. Let me explain the new BrowseAmp template engine so you also know what is coming up.

Most important: Not a single line of HTML code will be produced by BrowseAmp itself.
I talk about HTML code, but it can be whatever as you will see.

BrowseAmp tags
All HTML data is stored in template files that contains some layout tags or whatever you like and the BrowseAmp tags like <#songtitle> or <#artist>. Thats what you know from the old versions.

Cascaded templates
For example you can put an <#include file=playlist_template.html> statement into the main playlist.html. The <#include> tag is found and the specified file is parsed again with all BrowseAmp tags and so on. There is no limitation (yes, the memory  :rolleyes: ) how many steps you want to go through.

Creating playlist rows
To generate the playlist you add the following tag to playlist_template.html:
<#playlist template=playlist_row.html highlight=playlist_hlrow.html empty=playlist_empty.html>
BrowseAmp uses the file given in the template parameter for each line/song in the playlist. The <table> statements are needed in this example to create a table.
The 2nd step is to create a playlist_row.html that is used for every playlist entry:
  <td nowrap><#playlist_index></td>
  <td nowrap width="100%"><a href="?playtrack=<#playlist_songid>"><#playlist_songtitle></a></td>
  <td nowrap align="center"> <#playlist_songlengthmin>:<#playlist_songlengthsec> <a href="?removesong=<#playlist_songid>"><img src="../gfx/icon_trash.gif" border="0" title="remove '<#playlist_artist> - <#playlist_title>' from playlist"></a></td>
It's almost the same procedure to create the browser data. These examples are taken from QCD BrowseAmp.

As you can see, this is a great way to produce your XML data.
Feel free to ask if I missed an important detail.

I hope I can build a beta within the next few days.
FreeJack #11
Member since Mar 2003 · 10 posts · Location: nivaa, denmark
Group memberships: Members
Show profile · Link to this post
Wow, sounds really intersting, good method of customizing :-)

Might try and whip up a 'normal' skin :-)
Guest_genekeenan (Guest) #12
No profile available.
Link to this post
If you can spit out a complete xml document that would be really great for me because i would be able to make flash control the playlist also in addition to the regular controls.


Keefy #13
Member since Mar 2003 · 89 posts
Group memberships: Members
Show profile · Link to this post
genekeenan, from what I can see, it will be fully customisable what each XML page contains. You will be able to define an XML document exactly as is presently done with the HTML, where the BrowseAmp server will substitute your keywords for data. So you could create an XML page with all the information you desire, then request it. Personally, I'll be creating smaller pages to keep the data costs down.

Henry, thanks for the info, it should be an ideal way to do this. Does the server cache the files in memory? I'm just wondering how having multiple files would affect things like response time.

I've been busy on other things lately, so I've not done much for this. I was having trouble getting the XSL transforms to take place in Pocket Internet Explorer, but I've got this going now. I've got a small "proof of concept" collection of files that show the basics of how the XML/XSL could work when done client-side, these are in the attached ZIP. Simply open up the XML file in a browser to see it.

This was the only way I could get the transform to take place; ActiveX stuff (the normal way) didn't seem to work in the Pocket Internet Explorer browser. My next test will be to see if I can generate a page from multiple XML files, using the "document" XSL statement.
Keefy #14
Member since Mar 2003 · 89 posts
Group memberships: Members
Show profile · Link to this post
Oops, the ZIP didn't appear; second try:
The author has attached one file to this post: 588 Bytes
You have no permission to open this file.
Henry (Administrator) #15
Member since Jan 2003 · 865 posts · Location: Munich Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Henry, thanks for the info, it should be an ideal way to do this. Does the server cache the files in memory? I'm just wondering how having multiple files would affect things like response time.
I don't cache anything. I think the Windows and the harddisk cache is enough. And it runs really fast on my XP2000+ machine  :-p .

I'll test the XML stuff when I'm done with the new version.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next 
Go to forum
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Page created in 564.1 ms (302.7 ms) · 96 database queries in 218.7 ms
Current time: 2020-05-26, 22:30:04 (UTC +00:00)