Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product

[Ken Murchison <[e-mail]>]

On 11/23/18 12:56 AM, Neil Jenkins wrote:
> We also discussed the open issues at the JMAP session in IETF 103:
>
>>    o  Should we allow push notifications over the WS connection?
>
> The consensus in the room was "yes", we should use the connection we 
> already have. We would therefore need to:
>
>   * Add a tag to each JSON object sent through the socket so we know
>     what it is. I would suggest an |@type| property with values of
>     |"Request"| (sent by the client to the server), |"Response"| and
>     |"StateChange"| (sent by the server for API responses and pushes
>     respectively). (These are the names of the objects in the JMAP spec.)
>

Se already have @type in the problem details object returned for a 
request level error.  Can't the client simply check the response object 
for "methodResponses" , or "changed", or "type"? Otherwise, perhaps 
"responseType".


>
>>    o  Should we allow out of order processing of requests?
>
> Again the consensus was "yes"; you can use a single WebSocket 
> connection as the equivalent to parallel HTTP API requests. This means 
> we also need an |id| property on Request and Response objects so they 
> can be correlated by the client.


Should we make this "requestId" to be a little more descriptive? Or 
perhaps steal "tag" from IMAP?



>
> We probably also need to clarify that the core |maxConcurrentRequests| 
> limit is applies to inflight requests over the WebSocket. We may need 
> a new limit (exposed in the capability object) for establishing 
> concurrent WebSocket connections (although a client shouldn't really 
> need more than 1; that's the point)?
>
> Ken, are you able to update the spec and we can publish a new version 
> as a JMAP working group product? Thanks.


Sure.


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC