[pike]

you sure like to argue dontcha ?

note the " "

[jiz_king]

the ps2's browser has good js support i think. and with wifi built in it'd be a great remote.

did you mean the psp?

oops. of course i did.

[LiquidIce629]

lets bring this thread back to usefulness...

sorry for the delay folks, i got tied up with other projects... i just released the latest ajax interface for you to play with.

get it here:
http://www.xboxmediaplayer.de/cgi-bin....t=19418

some comments on the posts above

- getcurrentlyplaying (that's more efficient than the current one! and includes all tag info/thumbfilename)
- getplaylistcontents (that's got more detail)

these would definitely be useful.

also, this is a very good idea:

getthumbnail (since the file is off somewhere, what i did was filecopy to the q:\web directory to a temp file )

the method i'm using now to get the images does not cache anything so it will download a new image every time the track changes even if it is the same image. if you give the browser an actual url to the image it will be cached automatically.

i'm not a huge fan of replacing the http api with an xml based api. they could be used side by side, but to break all of the apps that use the current http api would be a shame. i think by improving the commands in the http api we can do a much better job at making a more feature backed web interface than starting from scratch with xml.
--

some problems i've found with the http api:

-the get thumbnail commands send the wrong path to the thumbnail. it returns q:\albums\thumbs\123456789.tbn
but the file is actually located in q:\albums\thumbs\temp\123456789.tbn

also in the manual the syntax for getthumbfilename is wrong.
this is how it wants it:
xbmchttp?command=getthumbfilename&parameter=smb://user:pass@host/mp3s/albums/baby%20-%20birdman;

the manual says it is looking for:
xbmchttp?command=getthumbfilename&parameter=album;filename
which will return an invalid thumbnail url.

--
the fact that the get thumb returns a path to an image even if it does not exist is annoying and wastes bandwidth trying to download invalid files. i looked at the source and i can understand why it was done this way because of the crc32 hashing. moving forward we should have a better command to get information on a file or directory that return all relevant info about it including if it has an actual image associated with it or not.

-wierd probelms when adding items to the playlist located at musicdb://

other than that i'm glad to see lots of activity on the web aspects of xbmc!

[TeknoJuce]

goofygrin dont worry about legacy support in youre version of the xmlapi just as the httpapi will have nothing to do with the xmlapi both of them will exsist if you wish for the xml one to do so its really not a big deal for them to both be availible to users that know about xml and for other users that dont know how to parse xml content ie: for users that just want to show some quick stuff in there browser window or build a quick app theres the current httpapi and for people that want to rack there brains and think xml is the way to go and want to build full featured apps they should have that choice also with youre incarniration of the xmlapi, i think the scuffle is where you think theres going to have to be support in the xmlapi for httpapi commands ie: legacy support as mensioned, where infact this is not the case. both will be two very seperate interfaces which excell to users to do there bidding with which ever they feel with their skill level they can use so no worries just you do what you can manage to do with the xmlapi and it will fit into the mix just like the rest of the jigsaw puzzle that is xbmc. sorry about the confussion best of luck with youre xmlapi.

[LiquidIce629]

just wanted to add another thought. a json (javascript object notation) api interface might be interesting.

json-rpc is lightweight remote procedure call protocol similar to xml-rpc. it's designed to be simple!

the way is could work is this.. there is a special json url on the webserver that listens for http get or post almost identical to the format of the current httpapi, and it would respond back with data in json format. this will allow objects and arrays to be easily passed to the interface which can include track information etc, in a nice format that will require little string parsing.

here is a (bad) example on their site that shows communication between the client and server:

--> { "method": "echo", "params": ["hello json-rpc"], "id": 1}
<-- { "result": "hello json-rpc", "error": null, "id": 1}

by using json, the api can be made available through the following programming languages:

actionscript, c, c++, c#, cold fusion, common lisp, delphi, e, erlang, java, javascript/ajax, lua, ml, objective caml, openlaszlo, perl, php, python, rebol, ruby.. and probably more.

some good information about json can be found at these links:
http://www.json.org/
http://json-rpc.org/
http://www.ajaxlessons.com/2006....otypejs

[goofygrin]

here's the wiki on json.... it's an interesting idea...

http://en.wikipedia.org/wiki/json

[pike]

nice short example from wiki:

json:

{"menu": {
"id": "file",
"value": "file:",
"popup": {
"menuitem": [
{"value": "new", "onclick": "createnewdoc()"},
{"value": "open", "onclick": "opendoc()"},
{"value": "close", "onclick": "closedoc()"}
]
}
}}

xml:

<menu id="file" value="file" >
<popup>
<menuitem value="new" onclick="createnewdoc()" />
<menuitem value="open" onclick="opendoc()" />
<menuitem value="close" onclick="closedoc()" />
</popup>
</menu>

[goofygrin]

here's a message i posted to the development group i work with on json:

title: xml is so 1999... json is where it's at!
body:
or so these guys would have you thing:
http://www.json.org/

http://en.wikipedia.org/wiki/json

the real benefit is this:

let's say you're doing some ajax stuff to get back a list of people:

<people>
<person id="1" name="joe blow" />
<person id="2" name="john smith" />
</people>

the equivalent json would be something like this:

{
"people" :
[
{ "id": "1", "name": "joe blow" },
{ "id": "2", "name": "john smith" }
]
}

let's say you need to cycle through the people and build a list of people with links to their name.

the javascript would be something like this for xml (not cross browser, required work for mozilla due to it's xml differences):

function makepeoplestringfromxml( xml )
{
// assume the xml is not in a dom already
var dom = new activexobject( "microsoft.xmldom" );
dom.loadxml( xml );
var nodes = dom.selectnodes( '/people/person' );
var resstring = "";
for( var i=0; i<nodes.length; i++ )
{
resstring += "<a href='viewperson.aspx?id=" + nodes[i].attributes['id'].value + "'>" +
nodes[i].attributes["name"].value + "</a>";
if ( i != nodes.length-1 )
resstring += "<br>";
}
return resstring;
}

the javascript for json would be (note that there're some security issues with this, but it's a one line change and a js include file, but it's trivial):

function makepeoplestringfromjson( json )
{
var people = eval('(' + json+ ')');
var resstring = "";
for( var i=0; i<people.length; i++ )
{
resstring += "<a href='viewperson.aspx?id=" + people[i].id + "'>" +
people[i].name + "</a>";
if ( i != people.length-1 )
resstring += "<br>";
}
return resstring;
}

note that the major differences are:
- crossbrowser for free (xml is way different in firefox than ie)
- no activex/com objects being created
- no xpath! (which actually can be a con, because there's a lot of times where i want to get the people with some attribute and it's obviously easier in xpath)
- no xsl transforms available (but they should be avoided in javascript anyway)
- the json method creates a lightweight object with properties that can be held onto/used in a variety of ways... holding onto an xml dom in javascript is one way to suck a lot of memory up quickly.

google and yahoo are using a combination of xml and json, so it does have some larger users out there...

just thought i'd throw this to ya'll to get your thoughts...

these are all .net, ms centric people, so it'll be interesting to see what responses i get

personally, i think it's a great technology, but getting people (e.g. clients) to accept it is pretty tough because xml continues to enthrall people from ceo on down the line (and working for a ms gold partner, i have to walk a tight line sometimes!.

now for xbmc, i'm all for making my life easier (although there are some benefits to xml with xpath...)

[Livin]

my question would be...

is json the way the "top" players (i.e. yahoo, google, etc) are moving forward or are they sticking with xml amily and json sparcely?

i'd say stick with what the future is and what is most cross browser compatible since you never know what browser may be on top next :lol:

[goofygrin]

my question would be...

is json the way the "top" players (i.e. yahoo, google, etc) are moving forward or are they sticking with xml amily and json sparcely?

i'd say stick with what the future is and what is most cross browser compatible since you never know what browser may be on top next  :lol:

the ol' crystal ball is a little murky these days, but:

msft is putting all their eggs into xml.  everything is xml now (office file formats, web services, infocrap err. infopath).  

google is doing whatever they want to do (and sometimes divergent things between groups, gmail and google maps used to [not sure if any more] use ajax in different ways [iframe vs. xmlhttp]).  they employ the father of python and pay him to develop the next version of it...

yahoo: are they even a major player any more?  they seems to just "follow the leader" so to speak. their maps competitor to google maps uses flash, for yet another type of "big boned" type client like ajax clients are.

[chadoe]

the way i see it is that json is great if you know the client is always a webbrowser.
if the client can be anything, browser/windowsapp/linuxapp/webservice/whatever, i usually stick with xml. i know there are json parsing libraries for just about any language but it seems silly to me to send javascript object notation to a client that likely doesn't even know the concept of javascript

(not sure what category we're talking here, well probably mostly webbrowser)

[Livin]

i'd think the focus is strictly browsers.

whatever works is cool.

i just cannot wait to have the multi-zone features and the ability to use the browser as a true remote!

[pike]

i don't know about you guys, but it doesn't feel good to release 2.0.0 with our current cvs "webgui"

i don't know if we should add xml or whatever before 2.0.0 darkie ?
if not we still need a bit fancier and foremost better working "webgui" for 2.0.0 imho

[darkie]

even with a xml api in cvs, don't expect a nice webgui for 2.0 any time soon. better to have a nice working gui for the current http api

[goofygrin]

(i've not got a lot of time, but i spent about 20 minutes looking at the current http code...)

i was not entirely sure why it starts to whack the cpu so much (e.g. the visualization loses fps) from the recurring getcurrentlyplaying calls, so i took a quick peek at the code...

here's the code (and my comments):

cstdstring fn=g_application.currentfile();

this is where we get sticky... this can be optimized to currentfileitem() which will speed up the stuff below as the fileitem has the tag on it and stuff.

tmp.format("%i",g_playlistplayer.getcurrentsong());
   output+=closetag+opentag+"songno:"+tmp;

gotta do this...

   int64)(g_application.gettime() * 10);
     output+=closetag+opentag+"type"+tag+":audio";
     const cmusicinfotag& tagval=g_infomanager.getcurrentsongtag();
     if (tagval.gettitle()!="")
       output+=closetag+opentag+"title"+tag+":"+tagval.gettitle();
     if (tagval.getartist()!="")
       output+=closetag+opentag+"artist"+tag+":"+tagval.getartist();
     if (tagval.getalbum()!="")
       output+=closetag+opentag+"album"+tag+":"+tagval.getalbum();
     if (tagval.getgenre()!="")
       output+=closetag+opentag+"genre"+tag+":"+tagval.getgenre();
     if (tagval.getyear()!="")
       output+=closetag+opentag+"year"+tag+":"+tagval.getyear();

get the current tag (which is on currentfileitem, so this call is somewhat redundant, but is in memory, so ok...)

     if (!g_infomanager.getmusiclabel(211).isempty())
       output+=closetag+opentag+"bitrate"+tag+":"+g_infomanager.getmusiclabel(211);  // musicplayer_bitrate
     if (!g_infomanager.getmusiclabel(216).isempty())
       output+=closetag+opentag+"samplerate"+tag+":"+g_infomanager.getmusiclabel(216);  // musicplayer_samplerate
   }

these two operations actually do some calculation for what should be a static field... i'd say that these values should be calculated once and cached.

   
if (fn.find("://")<0)
   {
     cstdstring thumb;
     cutil::getthumbnail(fn,thumb);
     if (!cfile::exists(thumb))
       thumb = "[none] " + thumb;
     output+=closetag+opentag+"thumb"+tag+":"+thumb;
   }

ouch... this hits the filesystem each time!  get once, then cache it.

   if (g_application.m_pplayer && g_application.m_pplayer->ispaused())
     output+=closetag+opentag+"paused:true";
   else
     output+=closetag+opentag+"paused:false";
   if (g_application.isplaying())
     output+=closetag+opentag+"playing:true";
   else
     output+=closetag+opentag+"playing:false";

gotta do this...

   if (lpts!=-1)
   {          
     int hh = (int)(lpts / 36000) % 100;
     int mm = (int)((lpts / 600) % 60);
     int ss = (int)((lpts /  10) % 60);
     if (hh >=1)
     {
       tmp.format("%02.2i:%02.2i:%02.2i",hh,mm,ss);
     }
     else
     {
       tmp.format("%02.2i:%02.2i",mm,ss);
     }
     output+=closetag+opentag+"time:"+tmp;

yeesh... can't we pass ms to the client and let them do this :d

     cstdstring strtotaltime;
     unsigned int tmpvar = (unsigned int)g_application.gettotaltime();
     if(tmpvar != 0)
     {
       int hh = tmpvar / 3600;
       int mm  = (tmpvar-hh*3600) / 60;
       int ss = (tmpvar-hh*3600) % 60;
       if (hh >=1)
       {
         tmp.format("%02.2i:%02.2i:%02.2i",hh,mm,ss);
       }
       else
       {
         tmp.format("%02.2i:%02.2i",mm,ss);
       }
       output+=closetag+opentag+"duration:"+tmp;
     }

err, isn't this the same code as above?  i'd bet that there's a common method somewhere for this!  i didn't look at the gettotaltime call, but i'd bet that's cached already...

     tmp.format("%i",(int)g_application.getpercentage());
     output+=closetag+opentag+"percentage:"+tmp;

the effectiveness of this depends on the player... i didn't look at the mplayer code to see what it does here...

     _int64 fs=filesize(fn);
     if (fs>-1)
     {
       tmp.format("%i64d",fs);
       output+=closetag+opentag+"file size:"+tmp;
     }
   }

ouch! another fs hit... this data is actually already stored in the fileinfo object: __int64 m_dwsize;




i'd say that with some simple caching (just local variables really), we could make this a much lighter call... i'd bet that some of the other calls could be optimized as well...

however, the xbox has limited memory... so more stuff being held onto probably might cause memory usage to go up... but i'd trade a couple bytes to not have to hit the filesystem (across the wire! every .9s for a song...

i'd bet with some simple optimizations, the current http interface could support some smoking remote (whether web, irc or thick client/pda client) apps.