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

["Neil Jenkins" <[e-mail]>]

On Fri, 23 Nov 2018, at 11:38 PM, Ken Murchison wrote: 
> 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". 

 
There's a `type` property on the problem details object but not an `@type` property. This object would also need an `@type` property with a value probably of `"error"` (or maybe `"RequestError"` would be better actually). The client can then simply look at this property on the object it receives to know what type of object it is and how to dispatch it. That's simpler and cleaner than looking for certain properties which should be on one type of object but not another (which you could easily screw up in the future by adding an extra property with a common name). 
 
>>>  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 could, but in general with JMAP if a property is an id of the object it is on, that property is always just called "id". If it's a reference to an id of another object, then it gets prefixed with a description of what's being referenced. So I think `id` is probably more consistent on the `Request` object, but maybe name it `requestId` on the `Response` object to show that is what it is referencing. 
 
> Is "clientId" in the request not sufficient for correlation? 
 
Yes, except what if the Request object returns a `RequestError` problem details object (as discussed above)? We need to know which request generated the error, so I think need to have a matching `requestId` property on this object. 
 
> Do we push ALL notifications or do we allow the client to subscribe to notifications for certain object types? 
 
We should allow clients to choose what types they want push notifications for, like we do with the other two push mechanisms. I guess we define an API method to configure this that affects the push channel it's sent down. 
 
Neil.