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

From: Neil Jenkins <[email-masked]>
Date: Sat, 09 Jun 2018 02:55:09 -0400

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.

---

From: Dave Richards <[email-masked]>
Date: Sat, 9 Jun 2018 18:36:56 +1000

Tom/Brad, do we do this, or are we pure WS?

Dave

> On 9 Jun 2018, at 16:55, Neil Jenkins <[email-masked]> wrote:
> 
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

---

From: Tom Smith <[email-masked]>
Date: Tue, 12 Jun 2018 10:13:42 +1000

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:
> On 9 Jun 2018, at 16:55, Neil Jenkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> 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.
>>
>> 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 would probably add an @type property to each top-level object 
>> (Response and StateChange) with the name of the type as the value.
>>
>> 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.
>> [email-masked] <mailto:[email-masked]>

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 11 Jun 2018 22:33:34 -0400

That's an interesting data point in whether to send push events down the websocket, but I think the question Dave was actually passing on was this one:

> 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.

Cheers,
Neil.

---

From: Brad Kowalczyk <[email-masked]>
Date: Tue, 12 Jun 2018 13:10:08 +1000

We use a separate URL

e.g. https://somedomain.com/events for SSE as opposed to 
https://somedomain.com/api for the core JMAP API

Cheers,

Brad

On 12/06/18 12:33, Neil Jenkins wrote:
> That's an interesting data point in whether to send push events down 
> the websocket, but I think the question Dave was actually passing on 
> was this one:
>
>> 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.
>
> Cheers,
> Neil.