Dear Tony, Thanks a lot for the review. Please see below for a quick response.
On Thu, Jul 20, 2017 at 5:14 AM, 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. > This is an interesting view: using an update stream resource to bring all ALTO resources together. > 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. > > > The current draft has some dependency/consistency requirements: - Sec. 7.6.2: Event sequence requirements, on updates of dependent resources - Sec. 7.6.3 Cross-stream consistency requirements - Sec. 10: Client processing when there are dependencies My understanding is that you are suggesting a subsection (or two subsections) on - IRD announcement, and one - subscription consistency Do I understand you correctly? > 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?). > Yes. > 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. > I believe that the media type in the "event" field can indicate whether this is a full or incremental (if so, which diff method). Does this address your issue or you are suggesting a more general solution? Thanks! Richard > > 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 > > -- -- ===================================== | 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
