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

[Tom Smith <[e-mail]>]

No, we use Server Sent Events, as per the original spec.

https://www.w3schools.com/html/html5_serversentevents.asp


Cheers,

Tom.



On 09/06/18 18:36, Dave Richards wrote:
> Tom/Brad, do we do this, or are we pure WS?
>
> Dave
>
>
>
> On 9 Jun 2018, at 16:55, Neil Jenkins <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> 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.
>> _______________________________________________
>> Jmap mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/jmap