[thor918]

have you thinked about persistent connection, and using events instead?

there are an ajax library that exploits flash capabilities trough javascript, enabling you to establish a connection that is kept open. check it out.
it works in ie.
i don't know if it works in ff.
it does not work in opera.

would be nice if it where support for opera, think about the new widgets feature in opera
i'm quite happy with the support in ie and ff.
thanks.

http://www.aflax.org/examples/sockets/sockets.html
(this would require an adapted server written in c++ or python, to handle the connections)

:o
listning.......

[goofygrin]

have you thinked about persistent connection, and using events instead?

there are an ajax library that exploits flash capabilities trough javascript, enabling you to establish a connection that is kept open. check it out.
it works in ie.
i don't know if it works in ff.
it does not work in opera.

would be nice if it where support for opera, think about the new widgets feature in opera
i'm quite happy with the support in ie and ff.
thanks.

http://www.aflax.org/examples/sockets/sockets.html
(this would require an adapted server written in c++ or python, to handle the connections)

:o
listning.......

negatory...

html is stateless... once you do this, you are no longer stateless and lemme tell you, this stuff isn't going to happen.

[thor918]

have you thinked about persistent connection, and using events instead?

there are an ajax library that exploits flash capabilities trough javascript, enabling you to establish a connection that is kept open. check it out.
it works in ie.
i don't know if it works in ff.
it does not work in opera.

would be nice if it where support for opera, think about the new widgets feature in opera
i'm quite happy with the support in ie and ff.
thanks.

http://www.aflax.org/examples/sockets/sockets.html
(this would require an adapted server written in c++ or python, to handle the connections)

:o
listning.......

negatory...

html is stateless... once you do this, you are no longer stateless and lemme tell you, this stuff isn't going to happen.

you mean http?

[thor918]

by the way i wasn't thinking of using http.
more like a lightweight server written in python.(or something in c++)
it was just an idea.

[goofygrin]

the idea is to create an interface which uses xml in a way it is intended to be used.

good

storing information in attributes is not realy the way it should be done in xml.

what?  you're alone here.

performance is another thing, it will be a bit slower. but is it really that much slower when parsing in a correct way??

the correct way?  parsing cdata is a pita, no matter how you slice it.  making requests that take cdata, from javascript is a pita too... (hell, making any request with a body is what i'd like to avoid).

cdata is only useful for strings that have a lot of &'s and < characters... &'s are easy to deal with and i bet that we'll have very few <'s to deal with (and they're easy too).

also keep in mind that file names and path names must be! in cdata elements because of special characters they can contain.

special characters all have replacement values (e.g. & amp.  most of the others are invalid for file systems anyway.

in any case, the only ones that would need converted are < > & ' " all of which are very easy to replace.

as far as i know, cdata elements cannot occour in attributes.

so what?  stay away from cdata if you can is what i recommend.

something else i had in mind was using xsl sheets. you can for example get the directory contents using the api, apply a xsl sheet over it and get a formatted html table back.

1. this doesn't buy you anything. (argue this point all you want, then go make something that uses xsl like this and you'll see what i'm talking about).
2. xsl don't work in javascript for crap (and if it does, it's very very slow).
edit: 3) repeat after me: "tables are bad, mkay" if you look at the source of the stuff that i wrote, there's no tables... just by changing the css, you can change any of the layout of the entire thing... (see http://www.csszengarden.com/)

i'm just a little grumpy today :veryangry: but this stuff really is my bread and butter...

[goofygrin]

have you thinked about persistent connection, and using events instead?

there are an ajax library that exploits flash capabilities trough javascript, enabling you to establish a connection that is kept open. check it out.
it works in ie.
i don't know if it works in ff.
it does not work in opera.

would be nice if it where support for opera, think about the new widgets feature in opera
i'm quite happy with the support in ie and ff.
thanks.

http://www.aflax.org/examples/sockets/sockets.html
(this would require an adapted server written in c++ or python, to handle the connections)

:o
listning.......

negatory...

html is stateless... once you do this, you are no longer stateless and lemme tell you, this stuff isn't going to happen.

you mean http?

yeah that

[goofygrin]

by the way i wasn't thinking of using http.
more like a lightweight server written in python.
it was just an idea.

so you mean another thick client?

get yer own thread :d  this one's for web clients.

edit: and how would you talk to the xbox? if not http then what protocol?

[thor918]

hehe.
i was tring to point out some possibilities with web clients.
..
anyway.
good work so far.

[darkie]

this xml api is not only for web pages. the idea is to let other applications communicate with it too.
what i also like to prevent is that in the feature it is not possible to extend the interface (because for example due to the choice of attributes) without braking older applications.

special characters all have replacement values (e.g. & amp.  most of the others are invalid for file systems anyway.

if those replacements are converted to their special character when parsing the data in a xml parser (so that you don't need to parse all special characers for every string yourself when reading the xml), its fine with me to remove cdata sections. and thus move some stuff in attributes.

however, if i parse an xml document with a certain xml parser and get results back like "some&apos;file.mp3" i am not so happy with dropping the cdata sections

[goofygrin]

again, it's your baby, so do what you want...

(no xml dom parser automatically will switch & to &, they all barf).

[jmarshall]

i think it was the other way around that darkie was referring to, which all xml parsers should handle i think?

goofygrin: you obviously have a lot of experience with this sort of thing, so please continue to offer your insight/suggestions/criticisms on the interface. we want to make sure we get it right from day one so that it can easily be extended to allow for new functionality without breaking other things. on the other hand, we don't want to make it too complex so that it never gets used (or is difficult to use efficiently.)

it might be useful if you could outline how you would set up the interface if you were to code it?

cheers,
jonathan

[drakethegreat]

honestly i think the xml engine is a bit slow. i don't deal much with the effiency of different parts of xml and how its parsed, but i have noticed that a lot of the interfaces people have been making are extremely slow when loading large directories of folders and audio files.

i work with a 45 gb library of music its big enough to really test how well things work. for example liquid's interface froze up because it was taking so long to loop through it.

on the other hand goofy's little interface is very responsive and its algorithm efficiency far exceeds that of liquid's yet at any event it seems the limitations in xbmc's api is slightly holding it back. that doesn't mean its a huge deal but its something that should be put on the agenda of up coming releases at some point.

as far as xsl... that just isn't a good idea for this sort of thing. ajax interfaces displaying via xsl seems to me like a bad idea. to be quite honest xsl is a nice technology but its usefulness only goes so far.

as far as implementing python or c++ socket servers to handle this is overkill and as goofy said, it should be moved to another thread if thats what thor is interested in doing. that would end up draining more of the limited memory on the xbmc and would give less flexibility to people like goofy when creating web remotes.

we prefer websites with ajax because its simplistic and its universal. web browsers support it and doing some protocol that isn't http is a bad idea (seriously no offense to you personally thor). to implement a server in python that was http is a bad idea as well because developers have more important things to do then build more http servers for specialized purposes. there is one already in xbmc that requires no modifications to the core itself and it is good enough because it supports ajax concepts for refreshless updating already.

note: please don't be affended by what i have said here. if i disagree with your ideas thats just a reflection of how i feel and not what should be done. my prior experience is web development probably has given me a biased opinion.

[Gamester17]

please excuse my stupidity here but how much more flexible is the http api interface by nad? and how integrated is it with webserver?
...if they aren't integrated could they be fused somehow to provide one common interface, or could http api function as pre-parser?

/ i'm probebly way off so please just feel free ignore me if i'm just talking rubbish, (i'm not a programmer or developer of any kind :nuts: )

[goofygrin]

please excuse my stupidity here but how much more flexible is the http api interface by nad? and how integrated is it with webserver?
...if they aren't integrated could they be fused somehow to provide one common interface, or could http api function as pre-parser?

/ i'm probebly way off so please just feel free ignore me if i'm just talking rubbish, (i'm not a programmer or developer of any kind :nuts: )

what you linked to is actually a thick client app that runs on your desktop or ppc that uses the same http api that i'm using to retrieve data/control xbmc.

if a different, xml based api was created, that app could be changed to use it and gain the efficiencies that that xml interface would, hopefully, provide.

[darkie]

i've played a bit with the xml interface how it is defined in the waka manual atm using xsl. i'm not saying this is a good way, but trying a few technologies is not that bad to learn something .
loading 20.000 directory items , parsing it and displaying, took something like 4-5 seconds, not very fast. but i have no idea how fast it is with the current http api.
since the current xml api it is not that good performance wise, it can get a lot faster if it is well defined.

and as jmarshall wrote, we need some people with experience for this to make it good, so goofygrin, i really appriciate it if you could help us out with this a bit. also know that i am not willing to push my own ideas in this xml api. it is just that i want to have a good understanding why certain decissions are good and why some are not. i'm doing a bit of work on websites too (not that much javascript and xml though) so i have some ideas about it. if those are good is another thing, but that is why i'm created a xml api from my first ideas (which is far form perfect) so that we could change the xml api according to the the decissions we make here. i hope you understand that.