Different REST resource for status updates

[GoogleCodeExporter]

The client app continuously makes HTTP requests (if using polling, not  
websockets) to a given sitemap page to update the widget's values of the 
current page. In answer the server returns a lot of unnecessary data, that is 
needed to build the UI, but now we need just to update widget statuses. Maybe 
it's a good idea to have another REST resource that only returns the possibly 
changed data - the icon and the value in a clean and easy (that means fast 
parsing) XML/JSON formatting. 

For example we use this resource to get the UI widgets data and build the UI: 
http://192.168.90.176:8080/rest/sitemaps/demo 

But we use for example this resource to get value updates for that page: 
http://192.168.90.176:8080/rest/sitemaps_data/demo 

This could returns only NAME (item name), ICON (widget icon) and STATE (item 
state) in a nice two dimensional JSON or nice XML.

Original issue reported on code.google.com by mishoboss on 22 Dec 2011 at 9:18

[GoogleCodeExporter]

How can one avoid that updates are lost?
Imagine two updates that come very quickly after each other. The request 
returns with the first update and before another "update request" is sent to 
the server, the second update occurs - and thus is not updated on the UI. Doing 
a "full" page update in every response does not solve this problem either; but 
at least on any third update, the second one will then be seen as well.

Do you have any performance data on how much it actually costs to update the 
whole page compared to just a single widget? I would think that this could 
possibly be neglected.

Original comment by kai.openhab on 22 Dec 2011 at 7:43

[GoogleCodeExporter]

Yes, with the ajax poll with some interval, everything between this interval is 
lost if it's changed more than once. The idea is to have short intervals, 
possibly every second. I'm not quite sure what will happen with websockets yet. 
Do you have any idea how this could be solved? Personally I think it's not a 
big problem if you don't see on the UI a status change that was less than a 
second.

> Do you have any performance data on how much it actually costs to update the 
whole page compared to just a single widget? I would think that this could 
possibly be neglected.

No, I don't have. My idea is actually to update the whole page, not the single 
widgets. That's why I ask for a simplified REST interface for that.

For example, you are on the Demo sitemap homepage and if we exclude the linked 
items from there (I think they don't need to update, or I'm wrong?) there you 
have only the Weather_Temperature item and the Data item. So the request would 
look something like this:

/rest/sitemaps_data/demo/demo

and the result would look something like this:

[
   {
      "id":"Weather_Temperature12345",
      "label":"Temperature [0,0 °C]",
      "icon":"temperature",
      "state":"Undefined"
   },
   {
      "id":"Date12345",
      "label":"Date [Вторник, 27.12.2011]",
      "icon":"calendar",
      "state":"Undefined"
   }
]

As you see I've put an ID attribute. I need to unique identify the widgets on 
the page to know which data for which widget is. This ID attribute must be 
presented in the sitemap REST API too, so I could build the UI widgets with 
these IDs. As there may be more than one widget on the page with the same item, 
the item name can't be used for that. So, I suggest to use item name + random 
unique number or just a unique number.

As we have spoken before, the text widgets have their value in the label 
attribute and the state attribute stays "Undefined". This is not a good 
practice, when every other widget type has the label in the label attribute and 
the value in the state attribute. I would be very happy if you make it as the 
other widget types. It would simplify and lightweight the widget update routine.

Original comment by mishoboss on 27 Dec 2011 at 8:51

[GoogleCodeExporter]

I didn't read closely enough, I actually thought this issue is already about 
suspended (websocket) requests.
I think the best answer is: Do not use polling with intervals, use websockets 
instead! (Should become available very soon.)

Anyhow, in order to get all status updates for a page, you have to refresh the 
whole page. It is not that you could exlude some widget types like group, etc. 
as in your example: Have a look at
http://localhost:8080/rest/sitemaps/demo/0300
where the labels of the group widgets can change as well on some item changes.

Original comment by kai.openhab on 27 Dec 2011 at 2:00

• Changed state: Rejected
• Removed labels: Version-later

[GoogleCodeExporter]

Well, I will use websockets when the device supports them, but also will use 
polling when they are not available. Websockets are not presented even in 
Android 4  ICS, so at least one more year on Android devices the only way is 
polling with some interval. 

What do you mean to refresh the whole page? To rebuild it again?  This is 
definetly not a good idea when doing RIA. Better build it once and then just 
update the widgets with new data. It is much more faster and betters the user 
experience. If group items change their labels, then we don't exclude them and 
update them too.

Original comment by d.panayo...@gmail.com on 27 Dec 2011 at 8:28

[GoogleCodeExporter]

> I will use websockets when the device supports them

Ok, I should have been clearer, I was referring to 
http://code.google.com/p/openhab/issues/detail?id=46.
This will use the atmosphere framework, which uses websockets, if available and 
falls back to cometd-like approaches if not. So whatever device you are using, 
you will get some server-push feeling and there won't be the need to do polling.

> What do you mean to refresh the whole page? To rebuild it again?

This depends on the UI framework what is possible. Of course it is always 
better to just do an update of the existing widgets. My point was mainly about 
processing all widgets of the page and not just a subset of it.
Btw, the current WebApp UI rebuilds the page, which is hardly noticeable by the 
user (no flickering or anything).

Original comment by kai.openhab on 27 Dec 2011 at 8:45

[GoogleCodeExporter]

> This will use the atmosphere framework, which uses websockets, if available 
and falls back to cometd-like approaches if not. So whatever device you are 
using, you will get some server-push feeling and there won't be the need to do 
polling.

Sounds nice. I have to read a little bit about the Comet technology and how to 
use it with Sencha (Sencha doesn't provide Comet proxy out of the box).

> This depends on the UI framework what is possible. Of course it is always 
better to just do an update of the existing widgets. My point was mainly about 
processing all widgets of the page and not just a subset of it.

OK, I forgot that group linked items could change their labels too, that's why 
I excluded them from the example. So, we don't exclude anything, just format it 
in a nice and easy parsing model.

> Btw, the current WebApp UI rebuilds the page, which is hardly noticeable by 
the user (no flickering or anything).

Well, not exactly. If you open it with Chrome on a PC and scroll the page down, 
every time the page is updated, the scroll goes to top position. This is just 
one of the reasons not to do that. Another reason is for example when you have 
a really heavy page - imagine a page with several cameras or several big 
charts. Sencha provides the necessary tools to do this right - just build it 
once and then just update statuses. And I will be very happy if there is an 
easy parsing and unified data model for status updates.

Original comment by mishoboss on 28 Dec 2011 at 9:33