[goofygrin]

if a new interace is added it is based on xml for sure wich will have only one url. meaning that you can't do something like http://xboxip/xbmcxml?command=something. instead everything will be xml based, both request and response. this means you have to set up an xml message in memory (with javascript for example) and send it to http://xboxip/xbmcxml  i don't think it is slower than the current way (you have to strip <li> and such atm)

xml can gum up the works quite a bit...

let's say you want to get the files in the current playlist.

it's really painful to have to post to xbmcxml with a body of

<?xml version="1.0" encoding="utf-8" ?>
<request>
 <action>getplaylistcontents</action>
 <parameter>1</parameter>
</request>

it's much easier to post to:
xbmcxml?action=getplaylistcontents&parameter=1

it's easier on the back end too (since there's no xml parsing, only the same type of logic that's already written).

in either case, i'd expect a return something like (using attributes to make the xml smaller/faster over the wire) -- also, set the response type to text/xml in order to make it truly an xml response (less hoops to jump through when using xmlhttp in the js side):

<?xml version="1.0" encoding="utf-8" ?>
<files>
 <file pos='0' name='coldplay - x&y.mp3' />
 .
 .
</files>

i've done both ways, and the second is significantly faster to develop on the back end (with less room for error, garbage in is easier to detect, no xml parsing issues) and way easier to write/manage on the front end.

[darkie]

yes, handling xml data does cost a bit more time to develop. but you will have much more freedom when creating something, and i think that it is worth it. also keep in mind that a lot of the functionality in xbmc is xml based. makes it much easier to add new functionality to the interface.
i havn't tried any xml parsing in javascript yet. but writing a function like

function(action, parameter)
{
 "<?xml version="1.0" encoding="utf-8" ?>"
 "<request>"
   "<action>" + action + "</action>"
   "<parameter>" + parameter + "</parameter>"
 </request>
}

isn't that much work and will give the same result (although it costs a bit more lines of code, it saves lots of code in xbmc's codebase ).
i agree that xml can be a bit of overkill for these simple commands. but imagine adding new shares to xbmc's configuration or listing directory contents (from multiple shares).

this is just how i see it, and since xml is a very common technology i believe xml is best suited for these kind of things.
note that it is not the idea that you have to send a request for every command or information retrieval. the xml interface should support something that makes it possible to request multiple items in the same xml packet.

what i had in mind

<xml>
 <request>
   <info id="total" item="player.totaltime"/>
   <info id="current" item="player.currenttime"/>
   <info id="12" item="system.freememory"/>
   <info id="file" item="player.currentfile"/>
 </request>
</xml>

[goofygrin]

the issue isn't that a function like you write isn't simple (it is), the issue is one of string concatenation.  strings in most languages (java, javascript, .net languages at the very least) are handled really poorly... so that a method like this:

var s = "";
s += "xyz";
s += "abc";
s += "123";

ends up making the following entries in the string table:
""
"xyz"
"xyzabc"
"xyzabx123"

so while you only needed the final string, you ended up taking 4 entries in the string table... which tends to bloat the memory usage of an app (among other things). [as an aside if you're ever debugging a program that does string concatenation for sql queries or page/control rendering and you're having performace issues, this is a very low hanging fruit to explore]

that's why a stringbuilder class and string.format are recommended in .net (in fact, ms made a javascript stringbuilder class and changed the string prototype to have the format method in their atlas framework for the same issue).

it might not seem like a big deal, but with the plausible amounts of data we're talking about (i've got 10000+ songs in my library), this can get very expensive.

you bring up a good point about batch methods (like move these three things to the playlist).  rather than making three calls, or one call with multiple parameters demarcated in some way (tilda? pipe?), you could have multiple nodes in the request...

still, i'd rather not have to write a big block of xml for atomic actions (set the volume, next file, back file)... maybe there's a middle ground? (although as i look at your example, other than at the initial startup, i can't come up with a scenario where i'd need those four pieces of information? -- i realize it was a forinstance, but i'd rather come up with concrete scenarios and work from there )

[Gamester17]

what about adding support a larger set of php (link) commands to the webserver as well or instead?, that should make it flexible too, shouldn't it? ...or would a php library/dll take too much ram?

[darkie]

supporting php will cost a lot of memory (2 - 5 mb?), and is not very easy to add to our current webserver. that is also the reason i was always pro python and http (aka spyce), the python intepreter is already in xbmc so doesn't cost extra memory. and at the same time you have access to all python commands. somehow this isn't very popular at the moment (python hard to learn or maybe bugs?), but if there exists a good php library, we can always have a look at it.

goofygrin, might be an intresting read
http://www.softwaresecretweapons.com/jspwiki....enation

[drakethegreat]

python isn't as popular of a programming language is the simple answer. most people don't want to learn another scripting language when it has such narrow applications.

[[email protected]]

the xml file i was making was based on the winamp xml file. i hadnt started on posting commands only receiving.

<?xml version="1.0" encoding="iso-8859-1"?>
<console><volume>37</volume>
<shuffle>0</shuffle>
<repeat>0</repeat>
<album><![cdata[beats of burdon]]></album>
<artist><![cdata[dj mike llama]]></artist>
<title><![cdata[llama whippin' intro]]></title>
<filename><![cdata[h:\ajax\winamp\demo.mp3]]></filename>
<length><![cdata[0:03]]></length>
<position>0.1</position>
</console>

this could be easierly implimented

[los93sol]

admittedly i'm not familiar with web development, but i've been working with the skinning engine quite a bit...after looking over the code for the web interface i got a huge headache rather quickly. assuming most skinners are in the same predicament as i am, we know the skinning engine and the xml's, but don't have a clue what to do with the web interface, maybe there's a better all around approach.

i think darkie is on the right track with talking about using xml's, but my idea is a little different, and this is where somebody with more knowledge would obviously be able to tell whether or not this is even possible, but here it goes:

in my opinion the web interface is part of the skin, but it's too difficult for most skinners to mess with because it is outside the scope of our knowledge, hence the lack of skins with their own web interface. maybe a good approach would be to develop the code for the web interface to work like the skinning engine so skinners could do it just like they would the normal skin, or maybe it could even be taken a step further to configure the web interface from the skins xml's. if this is possible then it would eliminate the web interface becoming outdated so quickly, and would allow the same experience from the web interface as if you were actually sitting in front of your xbox. i guess at that point you might as well have remote desktop which admittedly would be a little overkill, but then again, it'd be quite useful for developers troubleshooting remotely, and testing code remotely as well.

anyways, just a thought i had...

regards,
los93sol

[goofygrin]

as a developer who's looked at the skinning stuff, my head hurts

what i'd like is to make the interface (how we talk to xbmc) to be pretty open, so you can have multiple guis on top of it (say one for pda's, one for full featured clients, and one for the thick client apps like are in sourceforge now).

really, let's get to standards here, and skin using css. *that* would be the best way to handle skinning of the webapp.

[[email protected]]

its not just skinning that needs to be looked at but functionality aswell.

[[email protected]]

liquidice629 i did pm you but didnt get a reply. if i could take alook at your ajax pages that would be great. im working on one, and hoping to get in contact with blackbolt and his team because his skin does look very good and id like to design the ajax to match his skin. he did mention that he was planning on doing a webserver design but i dnt no if he started or if it was to be ajax.

[goofygrin]

i've emailed him with no response as well...

[drakethegreat]

ya liquid disappeared. he hasn't replied to me either after telling me he would contact me via aim (which he never did).

odd but it seems like if we do get his interfact it will be awhile. in the mean time i'm learning python just because it would seem php isn't a possibility (even though php pwns python in so many ways). i have little experience with ajax just because i hate designing gfx and programming javascript, but i'm definitely hoping that at some point i can help out with the backend of the web interface for xbmc.

[[email protected]]

im not sure his "web page" was even real, could just be a flash movie or something. but it may b who knows, im working on some graphics at the mo with a 360 style

[pike]

it was real, nice way to lure out the code there

i got an early copy of it. lets wait a few more days and if he doesnt resurface, i'll mail it to you.