Re: [alto] Some comments on draft-ietf-alto-incr-update-sse-07

["Vijay K. Gurbani" <[e-mail]>]

Lyle, all: Correct; I believe W3C SSE is the right choice here.

Many moons ago, when we were all very young (okay, ~3.5 years ago, but
we were still younger), there were other contenders; websockets comes to
mind [1].  But as the work progressed, it made sense to stick with W3C
SSE.

Cheers,

[1] https://tools.ietf.org/html/draft-marocco-alto-ws-02

On 07/24/2017 12:49 PM, Lyle Bertz wrote:
> All,
> 
> I asked during the meeting about whether or not it made sense to look at
> alternatives to W3C SSE.  However, in subsequent WG meetings such as
> netconf use of W3C SSE is the norm and the right way to go.
> 
> tl;dr - don't change the draft - keep the use of W3C SSE.
> 
> Lyle
> 
> On Wed, Jul 19, 2017 at 10:14 PM, xin wang <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Dear authors of ALTO Incremental Updates Using Server-Sent Events (SSE),
> 
> 
>     The draft about incremental updates by using Server-Sent Events
>     (SSE) proposes a general framework for incremental updates of
>     network information. The concept of update stream resource in the
>     framework allows a unified interface to ALTO clients. The interface
>     not only considers GET-mode ALTO services but also POST-mode
>     services, which should support most future extensions of ALTO
>     services. The following is my comments:
> 
> 
>     a. The benefits of the general framework
> 
> 
>     Besides of the extension-friendly design, I am thinking of other
>     benefits of bringing all ALTO services together by using a new
>     update stream resource. First, let me propose an alternative simple
>     solution of incremental updates. The solution views each
>     subscription independently, which means that each time a client
>     calls an ALTO service (e.g., get network-map) to get incremental
>     updating data, the server will establish a connection for the data.
>     Then, by comparing with the simple solution, we can find an obvious
>     benefit of the solution in the draft should be reducing redundant
>     connections. Also, another benefit would be that it makes removing
>     resources very easily. Though SSE itself supports disconnection API,
>     it will add new APIs to the simple solution. Moreover, because one
>     connection could manage multiple resources which may have
>     overlapping (also dependencies) between each other, I am considering
>     whether there exists an efficient way to make scheduling for
>     updating these resources.
> 
> 
>     b. Full replacement or incremental updates
> 
> 
>     In the client side, if the data is updated in incremental ways, then
>     there should be some algorithms to apply the updates like the
>     algorithm in Section 4.2.1. However, if the data allows full
>     replacement, then the client can easily replace the data with the
>     new one instead of applying the algorithms. Also, the
>     “incremental-updates” field is “true” indicates the server MAY send
>     incremental update events, which means that the client may receive
>     either a full replacement or incremental updates in each time (is
>     this right?). My idea is that if the response from the server can
>     indicate whether this update is a full replacement or incremental
>     one, the client should benefit from that.
> 
> 
>     Also, there are some typos may be fixed:
> 
> 
>     Page 10: "we now gives" -> "we now give";
> 
>     Page 13: missing “)” in "(see Section 6.3.”;
> 
> 
>     Best,
> 
>     X.Tony Wang
> 
> 
> 
>     _______________________________________________
>     alto mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/alto
>     <https://www.ietf.org/mailman/listinfo/alto>
> 
> 
> 
> 
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
> 

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: [e-mail] / [e-mail]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq