INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: rlebrette on August 10, 2012, 05:57:56 am
-
Hi JRiver team,
I would like to propose to include some evolutions in the existing API model as part of the new MC18 features.
I know it's less sexy than the "eye candy Theater View" feature, but I think that it could benefit to all users using gizmo/webgizmo/remote clients.
<technical-mode>
Today, implementing WEB 2.0 clients for MC is pretty easy, but it could be easier.
My first suggestion would be to provide a Websockets based API in addition to what already exists.
All recents web browsers are supporting websockets so this will provide two main advantages over what we already have in MC:
- Websockets are not limited with crossdomain restrictions (as AJAX $.get() is). With the restriction removed, *
the server providing the webpages can be different from the one which is used to provide the MC data.
- MC will be able to push events to clients rather than having clients polling the server, this will improve a lot the responsivness of the clients.
More MC will only send what has changed (time position only or track info only for example) rather than sending the whole pack of information as it's today.
The second one, is related to the format used in the API, since JSON is now a standard in data transfer and far lighter than XML,
it could be interesting to have the web API providing the data in JSON.
I've implemented a very simple prototype of a websocket server communicating with MC, and providing some basic features, this improves a lot what we can do on the client.
</technical-mode>
What do you think?
-
Thanks for the ideas.
Websockets look interesting. Pushing events would be quite useful.
As for XML vs JSON, I don't feel strongly. Since the existing MCWS uses XML, there would need to be a strong reason to change. If you enable compression (gzip request header), the packages get transmitted quite efficiently, so I don't think that's argument enough for a change.
-
The main advantage of JSON (over XML) is that data is natively transformed in JavaScript objects.
It means that you get an object in JavaScript that you can navigate and use easily, instead of having to navigate XML and DOM.
I think it's a pretty good improvement for a small investment, the nature of the MC XML data format is very easy to translate to JSON. (I assume that you have a generic function that convert all data in XML)
The output format could be an argument of the API. (JSON or XML)
My 2 cents.
-
+1 for JSON
-
I personally don't like the idea of moving to Java.
Many people don't want Java running unless absolutely required. It is a vector of attack for getting malware on your system.
Using Java would pretty much cut off the iOS ecosytem even more than it currently is from MC, and like it or not the iPad IS the current tablet market.
Java as an option, maybe. Java to replace XML, no.
-
I personally don't like the idea of moving to Java.
Many people don't want Java running unless absolutely required. It is a vector of attack for getting malware on your system.
Using Java would pretty much cut off the iOS ecosytem even more than it currently is from MC, and like it or not the iPad IS the current tablet market.
Java as an option, maybe. Java to replace XML, no.
Nobody talked about Java, just about JavaScript which is a totally different thing. (by the way it works perfectly fine whatever the OS is)
If you don't know about these technologies don't care it will change nothing for you as a user, except that Gizmo/JRemote and others will run smoother even on these "evil" Apple engines.