Re: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-00.txt

[Neil Jenkins <[e-mail]>]

On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:

• Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one?
  

Sure.  I'll add a 'wsUrl' String to the capabilities.

My question was genuine, I don't know whether this should be separate or the same. Does anyone here have experience running an API that's available over either websockets or HTTP? If so, would you normally put the websockets upgrade on the same URL, or a different one? Making it separate certainly gives you more flexibility, so seems like the right option to me, but I'd be interested if anyone has real-world experience.

• Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.)
  

I had intended that they would be in the same order, but I suppose out of order could be allowed if deemed necessary.

I think you definitely want this. This allows you to do concurrent requests with a single websocket, avoiding the overhead and complexity of creating multiple websocket connections to the server. 

• I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to be able to distinguish the different message types you might receive (API response or push).
  

Can't the client distinguish between a Response object and a StateChange object?  If we need a better way, do you have a recommendation?

I would probably add an @type property to each top-level object (Response and StateChange) with the name of the type as the value.

• What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension.
  

Are you thinking that we need separate maxSizeRequest, maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and maxObjectsInSet for the WebSocket connection?

No, these would still apply. It's more if you need extra ones: if you don't need to wait for a response to come back before issuing another request down the websocket, is this just counted as concurrent requests so subject to maxConcurrentRequests (I would say yes)? What about having multiple websocket connections at once? That probably needs a separate limit, because the request is no longer the same as the connection. Maybe maxConcurrentSockets or something.

Neil.