Building Dynamic Orbiters with JSON/AJAX/HTML5

[WhateverFits]

I personally love the concept of using JSON/JSON-RPC for doing this as I've been doing web development for more years than I care to admit. It is ridiculously simple to implement clients for it and I can make my own integration services based upon any number of technologies. This is excellent. However, I've seen interfaces done wrong more than once and that made dealing with it a living hell.

My only problem at this point with LinuxMCE development has been getting a full development environment up and running to work on a small piece of code. I don't have the time to devote to getting a full dev environment going but I can contribute small things here and there like supporting new devices, etc. So, how would I quickly set up something to work with this project?

[tschak909]

Read Developing a DCE Device, in the wiki.

-Thom

[uplink]

My plan is to port the AgoControl schema functionality to LinuxMCE. It shouldn't need any changes, but I'm yet to learn it. After that, whatever gets written should work on both simultaneously (fingers crossed).

[WhateverFits]

So Thom, you are saying this should just be a device in LinuxMCE that services JSON/JSON-RPC requests? Cool! Hmmm...

[tschak909]

Such a device would actually be a plugin, so it could have access to the data structures of the other plugins.

-Thom

[totallymaxed]

I personally love the concept of using JSON/JSON-RPC for doing this as I've been doing web development for more years than I care to admit. It is ridiculously simple to implement clients for it and I can make my own integration services based upon any number of technologies. This is excellent. However, I've seen interfaces done wrong more than once and that made dealing with it a living hell.

My only problem at this point with LinuxMCE development has been getting a full development environment up and running to work on a small piece of code. I don't have the time to devote to getting a full dev environment going but I can contribute small things here and there like supporting new devices, etc. So, how would I quickly set up something to work with this project?

Your welcome to get involved at the Core/NC end if you'd like to or at the client end of things using your Web development skills. Post to this thread if you have ideas or questions etc.

All the best

Andrew

[WhateverFits]

Your welcome to get involved at the Core/NC end if you'd like to or at the client end of things using your Web development skills. Post to this thread if you have ideas or questions etc.

All the best

Andrew

I'd like to get involved in both sides of that. I'll look at the plugin stuff as Thom mentioned. I've never looked at that type of code. Do I need a full development tree configured for this or can I just download the proper libs and etc. to get going?

[tschak909]

Grab the source tree, and do what is specified in developing a dce device.

-Thom

[Marie.O]

Soooo, did anything happen in the past month or so?

[WhateverFits]

I've pulled down a dev tree and started poking around at DCE devices. I think the hardest concept is the actual layout of the requests and responses. I'm learning how the DCE stuff seems to work and have been having some fun writing a bunch of my own devices for everything I own. Anyone else?

[uplink]

Soooo, did anything happen in the past month or so?

Of course not. That would go against our collective beliefs.

But just today I got a brilliant (for various definitions of "brilliant") idea that will probably become useful. I'm thinking of extending the "Execute Command Group" command that the DCERouter can handle to include user-specified and server-specified variables, a la Orbiter's SubstituteVariables.

Here's how it looks like:

You have a scenario that says "MH Play Media" with a parameter called "Entertainment Area" that has a value of "<%=E%>". That would normally be substituted by either OrbiterGen or the Orbiter (not sure which, don't want to check right now) to form a proper command.

So... I want to do this:

Execute Command:
PK_CommandGroup = 1
Variables: C:EA=2, where C is for "Client", EA is for "Entertainment area"

but also be able to use a S:IP variable in the scenario should I need it for whatever reason, where S is for Server, and IP is the Core's IP address.

Another potential variable that crossed my mind: S:MyEA - where the client just doesn't want to bother with looking up its own EA or Room, for various reasons (like it's not very economical for it, but really cheap on the Core).

An Orbiter would be able to operate sans-OrbiterGen, using only "Execute Command Group". You'd probably lay it out by dragging scenarios from a palette on the side or something. The Orbiter would be one way until a back channel is implemented (shouldn't be that hard if you know where to look and write a very generic data source counterpart of "Execute Command Group" - if there isn't one already of course).

[Marie.O]

afaik nobody knows about the EA I am in, other than myself. And for example iOrbiter, just forms the regular DCE command to be send to the router.

What I am trying to say is: In the above scenario I fail to see the advantage of variable substitution. But I only have had a single cup of java so far, so might miss the obvious.

[uplink]

Well... that idea came out of something else really. I'm going to abuse these light switches to trigger scenarios. Variable substitution is serious overkill on the client side (Whisperer) and they never change EAs once configured. While thinking how to do this, this crossed my mind: "dude, these switches are like tiny fixed-layout Orbiters".

All this because otherwise I'd have to add about 9 of these, with 9 scenarios each, and the prospect of RSI doesn't please me

[Marie.O]

Progress is always associated with lazyness.

[hari]

some progress on the ago control side. We've settled onto a MVC approach via ember js and jquery. It also supports templates and other nice things. Gumby is used for the appearance. Communication is done viai JSON-RPC. Getting the inventory (aka device list and stuff™), sending commands and receiving live status updates works fine so far. Still a lot of work to do but hey this is brand new, very hot, and will receive a lot love over the next weeks and months.