From what I see of the code in the branch, the console is packaged as a war, tha...
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.
Not sure I follow where the differences are. I am not seeing it.
There's no sec...
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.
Yes, it is HTML + JS, but served by and bound-to (at run time) an application s...
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.
Somehow I'm still failing to see the argument... the HTML and JS needs to be ser...
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.
Yes, at some point you have to deliver the static files.
You can do that from t...
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 (http://prism.mozillalabs.com/) 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.
Yes, that, but not only.
Also have just the controller REST API as server API. ...
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.
Yes, I'm thinking the same way. I think a static HTML and JavaScript is enough t...
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.
So there's two things here:
1) one is a Google Web Toolkit based rich web clien...
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.
Comments (17)
Jun 23, 2010
Jerome Velociter says:
I see there's a server package. Do you plan on getting rid of it and move to a p...I see there's a server package. Do you plan on getting rid of it and move to a pure client UI ?
Jun 23, 2010
Juha Lindfors says:
Explain what you mean?Explain what you mean?
Jun 23, 2010
Jerome Velociter says:
From what I see of the code in the branch, the console is packaged as a war, tha...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.
Jun 23, 2010
Juha Lindfors says:
Not sure I follow where the differences are. I am not seeing it. There's no sec...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.
?
Jun 23, 2010
Jerome Velociter says:
Yes, it is HTML + JS, but served by and bound-to (at run time) an application s...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.
Jun 23, 2010
Juha Lindfors says:
Somehow I'm still failing to see the argument... the HTML and JS needs to be ser...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.
Jun 24, 2010
Jerome Velociter says:
Yes, at some point you have to deliver the static files. You can do that from t...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 (http://prism.mozillalabs.com/) 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.
Jun 24, 2010
Juha Lindfors says:
Hmm interesting. I'm in agreement with your other point about REST interfaces v...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
Jun 24, 2010
Jerome Velociter says:
For local storage with GWT there is this project http://code.google.com/p/gwt-cl...For local storage with GWT there is this project http://code.google.com/p/gwt-client-storage/
Might be interesting to watch http://code.google.com/p/google-web-toolkit-incubator/ 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
Jun 23, 2010
Juha Lindfors says:
BTW, its an honest attempt to understand.. I know you know your stuffBTW, its an honest attempt to understand.. I know you know your stuff
Jun 24, 2010
Jerome Velociter says:
Trying to express it as sound as I canTrying to express it as sound as I can
Jun 23, 2010
Juha Lindfors says:
You are arguing for whatever client state to be stored in the user client (brows...You are arguing for whatever client state to be stored in the user client (browser) instead of server/session?
Jun 24, 2010
Jerome Velociter says:
Yes, that, but not only. Also have just the controller REST API as server API. ...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.
Jun 24, 2010
Juha Lindfors says:
You're right, that doesn't look right.You're right, that doesn't look right.
Jun 24, 2010
Mihail Panayotov says:
Yes, I'm thinking the same way. I think a static HTML and JavaScript is enough t...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.
Jun 24, 2010
Juha Lindfors says:
So there's two things here: 1) one is a Google Web Toolkit based rich web clien...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.
Jul 01, 2010
Juha Lindfors says:
The REST/JSON API for controller can be reviewed here: http://openremote.svn.sou...The REST/JSON API for controller can be reviewed here: http://openremote.svn.sourceforge.net/svnroot/openremote/branches/feature/Controller_API_JSON_Support
Controller 2.0 API document has also been updated with JSON samples.