Dear Lyle, all, Thanks a lot for the feedback. We will then continue to push the work forward as soon as we can.
Richard On Mon, Jul 24, 2017 at 4:52 PM, Vijay K. Gurbani < [email protected]> wrote: > 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 > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
