Hi Wendy, please see below...
On Mon, Sep 05, 2016 at 04:16:37PM -0400, Wendy Roome wrote: > Sebastian, > > Thanks reviewing the document. And thanks for keeping us honest! I will > address your major comment first, and then the minor ones in a later post. > > ***** SSE vs HTTP/22 Server Push: > > Yes, by the time this is published, HTTP/2 support will be more common. > Although not universal. For example, Java still does not support HTTP/2 as > a client, and will not until sometime in 2017. > > But comparing the two approaches, the primary advantage of HTTP/2 is that > it is officially blessed by the IETF. SSE will still be around for a long > time. > > And although HTTP/2 does allow a server to push unsolicited ages to a > client, using it for ALTO updates is a bit of a kludge. HTTP/2 server push > is designed for get-mode, static documents, like common images, css files, > etc. In effect the server tells the client, > > Here is the document with url FOO. > Add it to your cache. > You *will* need it!! > > To use that for updates, the server will have to encode in the url FOO the > information that this is an incremental update to a previously retrieved > resource. That is possible, but it is not clean, and does not fit the > HTTP/2 model. Furthermore, a client HTTP/2 library might hide the > server-push from the client by saving the pushed document in a cache and > delivering it to the client only when the client requests that url. > > And in addition, HTTP/2 is a very complicated protocol, which will > discourage embedded ALTO clients from using it. > > So given that, I think SSE is better, even after HTTP/2 becomes popular. > > BTW, I do not see HTTP/2 replacing HTTP/1.1. I think both will co-exist. > Simple web sites will use continue to use http/1.1; only complex, > heavy-load web sites will use http/2. This all sounds plausible to me. So, no need to revise your decisions, but maybe add some words to the draft. > ***** Could this be made optional? As in, give me the diff for the .. map > since tag ... > > Alas, that only works for maps with tags. Eg, that would work with Network > Maps. But it would not work for Cost Maps, or Endpoint Cost requests, or > Endpoint Property requests, etc. Could we use this draft to introduce a tag to the cost map, for the purpose of requesting diffs? Then, the mechanism would work with Network Map and Cost Map. These two are probably the most important targets for periodic incremental updates. > ***** I am not really convinced that in every scenario sending a keep > alive message every 15 seconds is more efficient than the client asking > for updates in similar time intervals. > > Keep-alives are much more efficient, because they just send 10 more bytes > on an existing TCP connection. Eg, one message. A request requires setting > up a new TCP connection. That takes several messages, involved allocating > new ports, etc. It is a lot more overhead on both the client and the > server. You are right, opening a new TCP connection every 15 seconds is less efficient than sending 10 bytes every 15 seconds over an existing connection, But there may be a break-even point ... What if I want the updates only every 120 seconds? Is one new TCP connection more effort than 8 keep-alives? Or 16? Maybe it is not worth the effort of changing the spec and adding some explanation is the better approach, but the current document leaves some feeling of strange asymmetry in me - one mechanism optional, the other one mandatory without a good explanation why. Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
