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.
***** 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.
***** 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.
- Wendy Roome
On 09/02/2016, 15:24, "alto on behalf of Jan Seedorf"
<[email protected] on behalf of [email protected]> wrote:
>Dear authors of the ALTO SSE draft,
>
>can you please look at Sebastian's comments (see below) and address them
>in a new version of the draft. Then, we can move the draft ahead (WGLC
>done, so next steps would be shepherd write-up and send out of the WG).
>
>@Sebastian: thanks a lot for taking the time and the good review/comments!
>
>Thanks,
>
>Jan
>
>
>On 09/08/16 14:31, Sebastian Kiesel wrote:
>>Hi Wendy and Richard, all,
>>
>>during the Berlin meeting our valued chairman have invited me
>>to do one more review of draft-ietf-alto-incr-update-sse-02,
>>so here it is:
>>
>>1. One general question
>>
>>this document tries to make distribution of updates to ALTO information
>>more efficient, in particular when network/cost maps are large and
>>change frequently. It leverages two separate mechanisms to do so:
>>a) an efficient encoding for smaller updates to JSON structures
>>(e.g. ALTO network/cost maps) and b) server-initiated notifications as
>>opposed to the client frequently asking for updates.
>>
>>For a), the document argues that JSON Merge Patch [RFC7386] is clearly
>>better suited than other similar mechanisms such as JSON Patch
>>[RFC6902]. I am not an expert in this field and just belive that this
>>assessment is correct. Furthermore, a client can de-facto disable this
>>mechanism by setting "incremental-updates" to false.
>>
>>So far, so good.
>>
>>For b), the document compares "SSE over HTTP 1.1" [W3C SSE Rec.] and
>>"HTTP 2 Server-Push" [RFC7540]. It argues that the second method is
>>technically superior, yet still specifies usage of the first one, in
>>order to allow faster deployment, as HTTP/2 libraries are not widely
>>available as of today. This seems to be a bit questionable to me, given
>>that getting this document published as an RFC will need at least
>>another half a year, but then it will live forever. What is the
>>timeframe we expect HTTP/2 implementations?
>>
>>But my main question is: could this mechanism be made optional, similar
>>to JSON merge patch? I'm thinking of a client-initiated request
>>(GET/POST), something along the lines "give me the diff for the .. map
>>since tag ... (if the diff is larger than the current map or the server
>>has not enough history information or CPU power to create the diff, send
>>the full map instead)".
>>I am not really convinced that in every scenario sending a keepalive
>>message every 15 seconds is more efficient than the client asking for
>>updates in similar time intervals. Maybe this client-initiated request
>>with JSON merge patch can be done, maybe I overlooked something? Adding
>>some lines of discussion may be worth it.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
