WebSockets comments for WD04

Resending with a subject line.

Note to self – OASIS email server rejects incoming emails with empty subject line...

-Craig

Hi everyone-

I’ve scratched out a little bit of text about the Watch usage in WebSockets. I’ve included it directly here, as well as in the attached doc – it’s based on Matthias’ version of wd04 that he sent me yesterday evening, so I think he’s made some changes since then.

Thankfully, it appears that my review comments from Word survived the copy/paste into Outlook, so I’d point out the questions I have about this still:

· names for the two properties – I’m not convinced these are the best names, I’d like something more succinct.

· redefining obix:Watch – this seemed to me like a questionable idea, but defining a new type would probably make seamless transitions between transport mechanisms more difficult. Pushing the properties up into the core obix:Watch would help, and we could default them to null to be compatible with non-WS servers.

· An unrelated comment, included in the attached doc – in para 1 of 2.1.3, I’d avoid restating the definition of the make operation on WatchService, and instead just reference it.

Thanks,

Craig

(The text below would replace everything in 2.1.3 after the first paragraph)

WatchService.make, when invoked in the context of a WebSockets session, behaves differently than when invoked with an ordinary OBIX session. The following behaviors are modified:

· The lease time property is not used.

· The watch is removed upon the close of the WebSocket session (or upon explicit client request through Watch.delete).

· The watch remains active without the need for the client to invoke pollChanges or pollRefresh.

· Invocation of pollChanges by the client will return an empty list.

· Change events are sent by the server directly to the client directly as unsolicited Updates.

All other behaviors function in the same way as defined in the core OBIX Specification. An OBIX Server that provides a watch in the context of a WebSocket connection MUST provide two additional properties for configuring the watch behavior, described below. The Contract for a watch that supports connection via WebSockets is:

<obj href="" style="mso-comment-reference:CPG_1;mso-comment-date:20131017T1424">Watch[CPG1] ”>

<reltime name=”unsolicitedBufferDelay[CPG2] ” min=”PT0S” writable=”true”/>

<int name=”maxBufferedEvents[CPG3] ”/>

The Implicit Contract for unsolicitedBufferDelay is the period of time for which any events on watched objects will be buffered before being sent by the server in an Update. Clients must be able to regulate the flow of messages from the server. A common scenario is an OBIX client app on a mobile device where the bandwidth usage is important; for example, a server sending updates every 50 milliseconds as a sensor value jitters around will cause problems. On the other hand, server devices may be constrained in terms of the available space for buffering changes. Servers are free to set a maximum value on unsolicitedBufferDelay through the max Facet to constrain the maximum delay before the server will report events. Servers may also use the maxBufferedEvents property to indicate the maximum number of events that can be retained before the buffer must be sent to the client to avoid missing events. Note that unsolicitedBufferDelay MUST be writable by the client, as the client capabilities typically constrain the bandwidth usage, whereas maxBufferedEvents is typically constrained by server capabilities, and is therefore not generally writable by clients.

obix message