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]> 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] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
