LinuxMCE Forums
General => Developers => Topic started by: totallymaxed on March 26, 2013, 11:54:21 am
-
Here at Dianemo we're in the early phases of exploring the notion of building 'Next Gen' Orbiters in HTML5/JSON/AJAX. The idea being to enable anyone with some modern Web technology skills to be able to design & implement new Orbiter UI's in a Web browser. These Orbiters will not be restricted by the current Web Orbiter implementation or be based in anyway on those ie they will not be based around a series of big whole Orbiter screen bitmaps generated at the Core and displayed in the browser. They will be built & designed like any other HTML5 page.
At present we're in the embryonic stages of implementing some prototype devices at the Core that will expose JSON objects representing some simple devices eg On/Off Lights & Dimmable Lights etc. We're several months, at best, from having enough working to have anyone play around with this outside our team. However it would be useful to be able to gage how many of you with the right Web Development skills would be interested in being involved in testing this capability when we are ready.
So please drop a post into this thread if your interested in getting involved when we are ready and have the right skills (you will need to be familiar with building Web services/sites using JavaScript/JSON/AJAX/HTML5).
Also If you have questions about what we're doing in this area then by all means post them here too... I may not be able to answer every question as we're still figuring this out but I will do my best to answer as fully as I can.
All the best
Andrew
-
Will it be fully compatible with LinuxMCE?
Can you describe the server-side architecture you are using?
What limitations, if any, should we expect to see in the finished version (relative to the current native orbiter feature set)?
-
Will it be fully compatible with LinuxMCE?
Can you describe the server-side architecture you are using?
What limitations, if any, should we expect to see in the finished version (relative to the current native orbiter feature set)?
Yes we intend to make this available to LinuxMCE and it will be GPL. There will definitely be a stage where it exists only in Dianemo...but that will short and will be before we open it up to a broader audience here. The idea is to get this broadly deployed and get as many people with UI Design/Web Developer skills using it as possible.
Other than what I have said already I can't say much more yet other than to say that the architecture will use JSON and will require client side Javascript code as you'd expect. As and when we have more specific details I will post them here and or on the wiki.
Re your question on limitations v 'Native' Orbiters; We don't expect or anticipate any limitations compared to existing Orbiters... in fact we expect the opposite of that in that you will be able to design new Orbiters on 'the fly' by just editing HTML/Javascript... the design/run/test loop should be very fast and dynamic. No regens will be required. Make a change in your Javascript code and test it. See the result. Adjust if needed and test again. Performance will be driven by the performance of your browsers Javascript engine and we really dont expect that to be an issue even on lightweight in wall panel style devices for example (we're testing one now with a full WebKit browser and in general terms it performs like an iOS device would.
Each Orbiter can have a different UI design deployed on it if that was a requirement... develop a small UI suitable for an Android mobile Phone or iPhone...its just a design problem not an engineering issue... it will be about defining how a tiny UI should be presented on such a device and performance will be like any other HTML5 based UI on that type of device. More efficient Javascript code will improve performance as you'd expect and it would be possible to write inneficient Javascript code and make your Orbiter perform badly of course... but then its just an issue of better coding to fix that.
Hope the above is helpful.
All the best
Andrew
-
maybe we can join efforts with ago control and come up with an abstraction layer that hides the innards of DCE/ago control and talk the same JSON-RPC protocol. I've added JSON-RPC to ago control recently, this page describes the current protocol: http://wiki.agocontrol.com/index.php/RPC
It should be straightforward to add similar methods to the DCE RPC plugin. I'd volunteer to implement this.
-
It appears I need to take a look at this Ago Control thing to see what it can do :) Bolting new features onto Pluto is getting a bit old.
Can it play media? If not, does it have the infrastructure in place? If not, I have a few ideas of my own - just not the time, or I'd jump right in.
The JSON-RPC interface can be designed in such a way that it's the same for both LinuxMCE and Ago Control. The way I see it, it should present high-level objects, and avoid providing access to the low level infrastructure as much as possible.
I'm still to invent what the data exchange protocol should look like, but I'm sure it has to NOT look like what's in the Ago Control wiki.
Here's a quick example I'm inventing as I'm writing it:
Request:
GET /lights/list
or:
GET /lights/list/+room/<id>
Reply:
{
"lights": [
{"id": "<id1>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
{"id": "<id2>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
{"id": "<id3>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"}
]
}
Request:
POST /lights/<id1>
{
"power": <on|off>,
"level": <0..100>
}
Reply:
HTTP/1.1 200 OK
Request:
GET /lights/<id1>
Reply:
{
"power": "<on|off>",
"level": "<0..100>"
}
That doesn't look like JSON-RPC. It's plain new RESTful. That's what I'd like to have. Essentially, the HTML5 Orbiter I have in mind won't be very different from a Web 2.0 web service.
As usual, I lack the time. While Andy made it sound like an HTML5 Orbiter is my main priority right now, that's not the case. I have some ideas, and I was hoping somebody else around here had enough knowledge to work on it, but I found out, after a few trials, that the person in question has a very steep mountain to climb first in terms of knowledge.
The concept is very promising. It just needs resources.
-
The reason why I chose JSON-RPC is that you can talk to it from a lot of languages in a standardised way. Media is on the list. We already have a lot of drivers in that area. What lacks is the logic that glues the things together and provides the user with a media browser.
-
totallymaxed, please use jquery as JS library, i'm sick of all the other JS libraries ....
;-) ...
-
polly, isn't jquery the browser side of things? Choose your weapon. I am sure the backend doesn't care.
-
totallymaxed, please use jquery as JS library, i'm sick of all the other JS libraries ....
;-) ...
No argument here: jQuery is what will be used.
-
jQuery is pretty much the only JS Framework i use ....
-
it is fairly simple to do JSON-RPC via jquery, e.g. setting a dimmer level does look like this in ago control:
function setlevel(uuid, level) {
var request = {};
request.method = "message";
request.params = {};
request.params.command = "setlevel";
request.params.uuid = uuid;
request.params.level = level;
request.id = 1;
request.jsonrpc = "2.0";
$.post(url, JSON.stringify(request), myCallback, "json");
}
So JSON-RPC barely adds overhad/code but provides a standardised way to talk to it. And that snippet isn't much more complex than concatenating specific URI strings. Coming up with dozens of /what/ever/it/might/be RESTful URLs ain't gonna make it easier in the long run. Specific URIs to fetch e.g. a list of lights are too specialised. A simple inventory request that delivers structured data with all rooms, scenarios, devices and states provides all that data in a single request. Plus it provides the schema. So the GUI knows what kind of actions the devices support. That allows for a generic widget approach (on, off, level, …). My two cents.
br Hari
-
hari thats the point! ....
even i understand jQuery without reading tons of documentation ..
-
Inventory command is OK. RESTful /what/ever/path/to/object doesn't interfere with it, it can just provide reduced sets when needed, rather than transferring a full schema all the time (reload Orbiter? :P). Both can co-exist on top of the same data layer.
I don't like the JSON-RPC structures because you have to wrap the useful data with extra crud that stays fixed. Are you planning to set request.method to anything else but "message"? Because only request.params contains useful information, and that's pretty much what I've exemplified. Any reason not to pass just the contents of request.params around?
I assume that you have libs that do json_rpc_call($method, $params), that's why you say it's "standard". So is ad-hoc JSON then :) The params are that ad-hoc JSON anyway. The method can go in the URL. I'd say that would be a lot more readable and properly separated. But that's just me. Hell, you could tail the web server log and see what commands are coming in (without their parameters), just to make sure you're sending the right commands or that the commands get to the server - helpful if your server isn't sitting there idle just for you and you need to grep the tail.
So, what I'm suggesting would look like this with jQuery for the example you gave:
$.ajax({
url: '/message',
method: 'POST',
data: {
command: 'setlevel',
uuid: uuid,
level: level
},
onSuccess: function() { do_my_thing(); },
onError: function() { moan_loudly(); }
});
RESTfully, it would look like this I guess:
$.ajax({
url: '/' + uuid + '/setlevel',
method: 'POST',
data: {
level: level
},
onSuccess: function() { do_my_thing(); },
onError: function() { moan_loudly(); }
});
Now that I wrote the second one, it does look a tiny bit uglier, because I have to compose that URL :) Hmm... But neither is uglier than JSON-RPC so far.
-
yes, there are other methods besides "message". Regarding the inventory, that is only fetched at the first load. You'll get notifications for changes when you subscribe to them on ago control. When listening to the proper events you can keep it up to date without needing a "reload". With standard I mean this: http://www.jsonrpc.org/specification
Adhering to it allows clients from multiple languages to talk to the service without much hassle. You can e.g. batch requests and have a defined set of result codes. Anyway..
-
Good day folks!
I just thought I'd point out a home automation controller with a well developed REST and SOAP/WSDL implementation that might provide some food for thought. It also has an AJAX library specific to it that leverages it's REST/SOAP interfaces, that's used as an embedded controller Web UI (it's main Admin/configuration app is Java based, but will likely be ported to something more HTML5 based in the future)
http://www.universal-devices.com/isy-developers/ look under the Official SDK section.
I'm pointing it out because it exposes lighting control, climate control and weather, energy measurement, etc via those REST/SOAP interfaces using XML. It exposes enough information that various GUI's can determine it's configuration and that of all the child devices, and present a GUI based on that information. It might give you folks some ideas...
HTH!
/Mike
P.S. that's the device I'm struggling to write a GSD driver for, so if Hari feels like whipping one up for Ago Control, I'd be happy to test. I can't 'C' my way out of a wet paper bag ;-). I've been playing with Ago a bit on my Pi. Want to have some free time for hardware hacking so I can play with your Blink-M stuff (once I build a few clones). /M
-
yes, there are other methods besides "message". Regarding the inventory, that is only fetched at the first load. You'll get notifications for changes when you subscribe to them on ago control. When listening to the proper events you can keep it up to date without needing a "reload". With standard I mean this: http://www.jsonrpc.org/specification
Adhering to it allows clients from multiple languages to talk to the service without much hassle. You can e.g. batch requests and have a defined set of result codes. Anyway..
OK, I'll fold (for now?). The main purpose is to see where an HTML5 Orbiter can get us. If it's JSON-RPC that will be the information transport method, then so be it. :) I'll install Ago Control in a Virtualbox some time and have a play with it in the following days or so, then attempt to whip up a crude web interface for it.
Do you have any virtual devices I can configure? Or are they easy to make? I don't have any physical devices I can use with Ago Control right now, so a few fake ones (like, say, Upnp_Light) would be helpful :)
-
there is a simulator available, it will provide some fake devices. Ping me on IRC when you're going to have a look, I'll be more than happy to assist. Just be warned that the current resolver component was rewritten in c++ and still has some issues. There is a python one, too, which is quite stable already.
-
there is a simulator available, it will provide some fake devices. Ping me on IRC when you're going to have a look, I'll be more than happy to assist. Just be warned that the current resolver component was rewritten in c++ and still has some issues. There is a python one, too, which is quite stable already.
/me likes Python :)
-
maybe we can join efforts with ago control and come up with an abstraction layer that hides the innards of DCE/ago control and talk the same JSON-RPC protocol. I've added JSON-RPC to ago control recently, this page describes the current protocol: http://wiki.agocontrol.com/index.php/RPC
It should be straightforward to add similar methods to the DCE RPC plugin. I'd volunteer to implement this.
I'm coming in late on the discussion on this but I think Uplink is warming to using JSON-RPC & seeing what we can do with ago ;-)
So joining efforts is exactly what we should do now we (or 'I' more likely!) understand your interested in much the same thing we are. If we can develop a common set of tools for Orbiter/UI building in LinuxMCE/Dianemo & ago that frees us all up from the current dependencies on PPL and also liberates us to build UI's that are not frozen in the past or reliant on the UI designer knowing anything more than some standard Web technologies like JSON/Javascript etc then that a big win.
What I'd like to see in this thread, in addition to the very important discussion about the Core/Backend technology, is some people step forward who have good Web based skill sets and have built projects around JSON/Javascript. In addition anyone who is willing to learn those skills and dig into building new Orbiter UI's using this stuff - lets hear from you too.
What we're discussing here will open up LinuxMCE/Dianemo/Argo development & allow a much broader group of people to participate in what we do here. And that can only be very positive development for the community.
Andrew
-
What I'd like to see in this thread, in addition to the very important discussion about the Core/Backend technology, is some people step forward who have good Web based skill sets and have built projects around JSON/Javascript. In addition anyone who is willing to learn those skills and dig into building new Orbiter UI's using this stuff - lets hear from you too.
*me steps forward*
im a web guy for quite a while now ....
@work i create webpages based on TYPO3, using jQuery and jQuerUI as Javascript Framework. Sometimes a bit server administration stuff ... thats it.
Im not too bad @ designing stuff (i reckon) ... ;-)
Cheers,
ochorocho
-
*me steps forward*
im a web guy for quite a while now ....
@work i create webpages based on TYPO3, using jQuery and jQuerUI as Javascript Framework. Sometimes a bit server administration stuff ... thats it.
Im not too bad @ designing stuff (i reckon) ... ;-)
Cheers,
ochorocho
Great :-)
Keep an eye on this thread and join in the conversation if you can.
Welcome.
Andrew
-
I am replying, after a few days of mulling over an appropriate response.
Those of you who have been a part of this community, since the beginning, remember all the discussions that have been had, over and over again, over a next generation user interface, to replace Orbiter. We spent from 2007, until 2011, just _TALKING_ about it.
and _everybody_ had an opinion.
Lots of people just talked about it...over and over, with nothing getting done...
until...
golgoj4 finally sat down and _DID_ something. He has thus far built a functional orbiter engine, but it needs qml.
Yes, I understand what and why you guys are doing this, but by doing this, you're fragmenting developer resources even more than what we already have!
So basically, you're keeping this under wraps, until you're "ready" to show it off. Throwing it over the wall.
This didn't happen with qOrbiter. Langston put qOrbiter in the source repository from day one, and those of us who could, checked it out, built it, and tried to build things with it, and we did this from day one. golgoj4 built his basic skin, and I was building my skins for Harmattan, and more recently, for Android. And boy, did we discover all these little bugs, and things that needed to be refined. But only because the whole development process was open from the beginning.
So, fine. If you want to fragment developer resources, that's your perogative. But, trying to keep all this behind the wall, without any contribution from anyone else, is setting yourselves up for some nasty surprises when people start trying to build stuff with it.
-Thom
-
Yes, I understand what and why you guys are doing this, but by doing this, you're fragmenting developer resources even more than what we already have!
You mean people that don't have the skills to help out in other areas will become scarce, so you'll have smaller numbers of people who can't code in other areas on interest? :)
So basically, you're keeping this under wraps, until you're "ready" to show it off. Throwing it over the wall.
What wall? We haven't even started any code yet. We're... err... talking about it :) We're having meetings about what we should discuss in our meetings :D
The plan is to start something, no matter how stupid, and hope people like polly take over once we have an idea about what we're getting into. Then we get a github repository or ninety (such is git :P).
-
Well, totallymaxed initial statement hinted at: Dianemo will develop stuff inhouse, and once ready will open it for others, as opposed to what you are saying now... ;)
-
Well, totallymaxed initial statement hinted at: Dianemo will develop stuff inhouse, and once ready will open it for others, as opposed to what you are saying now... ;)
totallymaxed is a bit overenthusiastic about it :) We don't have the manpower. All I can do is get this ball rolling and hope it snowballs.
We ran some very basic experiments, using dummy, ad-hoc data and structures. I was hoping another guy we know would be able to help out. He can't, on grounds of inexperience. This idea came about after I started working with HTML5 and jQuery for an unrelated project, then remembered the iOrbiter... which isn't that fancy, but it's acceptable in some environments. The idea was that I write some stupid UI using HTML5 and AJAX so there's a starting point, and then hand it over to whoever to continue it, 'cause I have a lot of other work to do :)
-
I think it sounds very interesting. I am a web developer and use various java frameworks, javascript (jquery), and often times use json to exhange data between different systems. Ive been using linuxmce for about 4 years and have created some basic device templates in the past. I have tried the UIDesigner in the past (but wasnt successful) and have a few devices that have had the web orbiter running. I currently have 3 mds and a hybrid with ATSC tv, hd using vdpau, video cameras (both analog and IP), and two WEBDTs.
I havent had a whole lot of free time lately because of work, but If you need a hand with something send me a PM.
-
Well, totallymaxed initial statement hinted at: Dianemo will develop stuff inhouse, and once ready will open it for others, as opposed to what you are saying now... ;)
Starting this thread was an attempt to see how many people in the community had the relevant Web based development skills and would be interested in getting their hands dirty and get involved. Obviously the thread has an expanded scope now...but that was my initial intention nothing more.
To help people understand what we were planning I explained our intentions so that everyone understood where this was coming from. Therefore initially I thought that we'd do the first steps internally here... do some basic stuff using Uplinks thinking on this (which has been going on for some time) and then open it up a little to people who had the Javascript/JSON/JQUERY skills to work on actual Orbiter UI's. At the same time if anyone wanted to dig into the Core end of the code they could do that too. I did explain that it would be sometime before we would be ready with anything to test against based on our own internal development resources... but of course with Ago we may get there faster than anticipated.
However things have moved on and it looks like Hari and his Ago project are going to be the basis of what we all build on to create a 'bridge' to LinuxMCE/Dianemo Core's. So we're not doing anything behind 'the curtain' at all everything is perfectly in the open. As Uplink has said here already I don't see any of this as fragmenting development resources as no one as far as I know that has voiced an interest so far has the skill or the inclination to get involved in qOrbiter. To be frank one of the major reasons we like the Ago/Javascript/JSON approach is that it opens up Orbiter development to a much broader audience and free's anyone designing an Orbiter UI from the limitations of both yesterdays Orbiters and HA Designer. In addition our approach here further simplifies the skill-set required to work on Orbiters in that you don't need to understand anything more than standard Web 2.0 style development.
We think this approach has a lot going for it.
All the best
Andrew
PS sorry for the typo in the original post where i confused the movie 'Argo' with Hari's Ago project... Freudian slip ;-). Typo now corrected!
-
/me is sure hari does not like his project to be associated with argonauts...
-
Well... so far I'm stuck with AgoControl, because setting a room for a device crashes AgoAdmin :D It crashes after it saves, so a restart of the services brings everything back, but it's quite annoying, so I'll wait for it to get fixed.
-
/me is sure hari does not like his project to be associated with argonauts...
Ooops!...Argo is a movie :-)....Ago is Hari's project of course.
Andrew
-
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?
-
Read Developing a DCE Device, in the wiki.
-Thom
-
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).
-
So Thom, you are saying this should just be a device in LinuxMCE that services JSON/JSON-RPC requests? Cool! Hmmm...
-
Such a device would actually be a plugin, so it could have access to the data structures of the other plugins.
-Thom
-
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
-
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?
-
Grab the source tree, and do what is specified in developing a dce device.
-Thom
-
Soooo, did anything happen in the past month or so?
-
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?
-
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).
-
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.
-
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 :)
-
Progress is always associated with lazyness.
-
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.
-
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.
Hari - did the bug Uplink reported that caused Ago to crash when a device was placed in a 'room' get fixed?
Andrew
-
afaict yes
-
afaict yes
Well... it still blows up, but slightly differently. I get the error only 50% of the time now, and refreshing the page gets me my page back without having to restart everything.
An error occured in a template
/opt/agocontrol/admin/agoadmin.py:231 default inventory = discover()
/opt/agocontrol/admin/agoadmin.py:79 discover if message.content:
Where exactly can I see this emberjs thingy? :)
-
maybe you can provide a more detailed bug report, e.g. what exactly you're doing. Are there any messages in syslog? Adding devices to rooms works fine (we've no other reports that indicate otherwise). But for the records, this is the old web admin written in cherrypy. The new interface is served via agorpc on port 8008. Just make sure to install the latest package.
-
the source is here: http://www.agocontrol.com/trac/browser/agocontrol/agocontrol/core/rpc/html
-
maybe you can provide a more detailed bug report, e.g. what exactly you're doing. Are there any messages in syslog? Adding devices to rooms works fine (we've no other reports that indicate otherwise). But for the records, this is the old web admin written in cherrypy. The new interface is served via agorpc on port 8008. Just make sure to install the latest package.
OK, after updating my svn copy and running the updated agosimulator.py it doesn't go kablooey anymore. It appears that was what tripped it.
-
Nearly another month went by, since the last time I asked if anything happened...
So, did anyone make any progress within the LinuxMCE/Dianemo space with regards to HTML/JSON/RPC whatever?
-
Well, I've been working through Hari's JSON-RPC code and looking at how to do that type of thing in LinuxMCE. Mostly I've just been trying to get stuff to work.