This page last changed on Jun 22, 2010 by juha.

For those interested and waiting for a web console, we've started the work on here:

I see there's a server package. Do you plan on getting rid of it and move to a pure client UI ?

Posted by jvelociter at Jun 23, 2010 10:17

Explain what you mean?

Posted by juha at Jun 23, 2010 13:06

From what I see of the code in the branch, the console is packaged as a war, that contains server code (all packages but org.openremote.web.console.client).

My idea of the Web Console would rather have been a pure static HTML + JS UI. This way you don't need another app server for it, you just care about your ORC being up and running (same setup as if you use iPhone/iPad native client) and that's it.

I've given it thoughts and so far I don't see anything you will miss if you have just a client (or put another way, I don't see a good enough reason why you would want a server component). You can use localStorage for user settings/mappings ; JSON-P support on the controller REST API to allow cross-site AJAX, etc.

Posted by jvelociter at Jun 23, 2010 13:56

Not sure I follow where the differences are. I am not seeing it.

There's no second app server, the web client is served from the ORB. It is HTML + JS, either GWT compiled for full-scale browser or reduced for mobile clients.


Posted by juha at Jun 23, 2010 14:10

Yes, it is HTML + JS, but served by and bound-to (at run time) an application server running the Web Console webapp.

Of course, you can always serve it from the same tomcat/JBoss you have on the ORB (the one that runs the controller). But in the end, it's still something more to deploy and to maintain.

My point is that I don't think the servlet part (or read "everything that does not get compiled to JavaScript") of the current Web Console is even needed.

Posted by jvelociter at Jun 23, 2010 14:42

Somehow I'm still failing to see the argument... the HTML and JS needs to be served from somewhere... and the controller is already on Tomcat... so... I don't understand your point.

Posted by juha at Jun 23, 2010 19:35

BTW, its an honest attempt to understand.. I know you know your stuff

Posted by juha at Jun 23, 2010 19:45

You are arguing for whatever client state to be stored in the user client (browser) instead of server/session?

Posted by juha at Jun 23, 2010 19:50

Yes, that, but not only.

Also have just the controller REST API as server API. Here from what I understand of the code, you will end up with an intermediary layer (GWT-RPC API + impl) between the browser and the controller. This is what I think is not needed. Take the iPhone/iPad, you only have client code directly talking to the controller REST API, right ? No intermediary webapp that does the plumbing. I'm seeing the Web Console just like this. Main advantage I see is less code to maintain, and all clients talk the same API.

Posted by jvelociter at Jun 24, 2010 10:43

Yes, at some point you have to deliver the static files.

You can do that from the ORB itself. But you could imagine the scenario where you distribute the web console as a prism'ed application ( for the desktop, that comes with the JS/HTML files bundled. And soon enough, probably for the mobile/tablets as well - I'm confident it's in Mozilla plans to bring Prism to Fennec. From that point you can distribute the web console in stores (Android, Meego, etc.) just like you do with native consoles.
But for that you have to be really independent of any local server deployment/settings (just as for the ipad/iphone clients), and get rid of the server jars.

Posted by jvelociter at Jun 24, 2010 10:57

You're right, that doesn't look right.

Posted by juha at Jun 24, 2010 10:58

Trying to express it as sound as I can

Posted by jvelociter at Jun 24, 2010 10:59

Hmm interesting.

I'm in agreement with your other point about REST interfaces vs GWT-RPC use.

For local storage, I assume GWT abstracts this work away (I haven't checked) but we would be covered there for stand-alone browser use.

Mobile browsers were a concern of mine so if Mozilla can push Fennec and additional pieces into that domain, then could be interesting.

Thanks for giving an update what we might see in the future. Please keep posting

Posted by juha at Jun 24, 2010 11:04

Yes, I'm thinking the same way. I think a static HTML and JavaScript is enough to build an interface based on XML and then communicate with ORB via REST. This must be just a thin client to ORB, not another server-side application with client.

Posted by mishoboss at Jun 24, 2010 14:42

So there's two things here:

1) one is a Google Web Toolkit based rich web client that works on stand-alone web browser (ie. if you want to control things from your laptop)

2) There's a light weight version which is mainly intended for mobile browsers

The GWT version is using GWT-RPC to get a free serialization implementation, JSON is preferred over XML due to lighter weight parsing and support that exists in jQuery et al.

Frankly I don't care that the GWT app uses extra plumbing on the server. Less work for us, better. It buys a quick implementation of XML domain objects from the server to client.

JSON based REST API will come with the mobile browser view.

Posted by juha at Jun 24, 2010 14:52

For local storage with GWT there is this project

Might be interesting to watch too. I recall there are some classes in it that relates to HTML5 features.

I imagine that at some point all that will end up on GWT roadmap.

I'll keep watching the evolution of the Web Console. I'd like to get involved more actively. Hard part is making time... usual story

Posted by jvelociter at Jun 24, 2010 15:55

The REST/JSON API for controller can be reviewed here:

Controller 2.0 API document has also been updated with JSON samples.

Posted by juha at Jul 01, 2010 15:19
Document generated by Confluence on Jun 05, 2016 09:32