Re: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded

Hello,

I found some time to have a look on the proposed Web socket binding.

I have some suggestions for changes that can be split into two design options, which are mereley:

-) Option 1: Using SOAP for the Web Socket binding or

-) Option 2: A Web socket connection represents one concrete instance of a Watch acting as a per-client state object

Option 1:

The question is if we want to expose the full oBIX protocol over Web sockets. The issue is here the RESTful design that resides at the core of oBIX. Every object is identified using a URI and the protocol is mapped to the HTTP protocol verbs. Furthermore the oBIX protocol more or less assumes a request/response interaction for message exchange, since oBIX does not provide any means to map request and response messages.

Protocol messages:

You have addressed this by defining oBIX objects for request, response and update (Line 122 to 129) --> similar wrapping types have been defined for the SOAP binding. We could reuse them.

Mapping responses to requests:

For this problem you want to add a message id, as facet. This brings information that is related to the issues the transport protocol to the application layer. If we use SOAP, the WS-Addressing standard would provide according features to support correlation of messages for asynchronous transports that do not have a request/response interaction semantic.

So as a conclusion for this design option I would suggest to use SOAP + WS-Addressing over Web sockets to rely here on already established solutions.

Option 2:

Maybe the Web socket binding could be much simpler, since we just want to take the advantage of the async. communication capabilities of Web sockets. For "normal" protocol interaction we can stay with the regular HTTP binding.

Assume that if a client connects using Web socket a Watch is created and all the interaction over Web Socket is based on WatchIn and WatchOut messages. The Watch operations are not available and follow an implicit definition. Like if a WatchIn is passed with a list of hrefs, all referenced objects are observed. If href is passed again it is removed from the watch.

In this case we don't need to map the protocol interactions and the correlation of requests and responses is also not really an issue. Since the client can just assume to receive WatchOut objects with updated oBIX objects over the Web socket connection. PollRefresh is not available but in that case the client could also use the regular HTTP binding to poll the current state of objects.

Please take this just as my subjective comment. It would be really interesting to hear the opinion of the other TC members on this topic. Maybe we can have a discussion on this topic in one of the next telcos.

Unfortunately I cannot join the telco today.

Bests,

Markus

Am 15.08.2013 02:57, schrieb Matthias Hub:

obix message