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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto > <https://www.ietf.org/mailman/listinfo/alto> > > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks Email: [email protected] / [email protected] Web: https://www.bell-labs.com/usr/vijay.gurbani Calendar: http://goo.gl/x3Ogq _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
