Re: Revised Incremental Update draft

Wendy Roome <w.roome@...>


Thanks for your comments. My responses in-line.

From: <yang.r.yang@...> on behalf of "Y. Richard Yang" <yry@...>
Date: Wed, September 23, 2015 at 16:04
To: Wendy Roome <w.roome@...>, alto-design <alto-design@...>, "alto-dev@..." <alto-dev@...>
Subject: Re: Revised Incremental Update draft

Here is some feedback:
- I liked the addition of the changes-since-00 section. It helps. I believe that it will be removed at the final stage.

Yes, I expected that. Do you think it is worth mentioning that in the section?

- Sec. 4.3: Why not use the empty event keep-alive. Does an empty event still indicate a keep alive? (xref target ) seems to be missing < 

Because the SSE specification recommends that as a keep-alive. From Section 8:

Legacy proxy servers are known to, in certain cases, drop HTTP connections after a short timeout. To protect against such proxy servers, authors can include a comment line (one starting with a ':' character) every 15 seconds or so.

I will expand Section 4.3 and say that SSE recommends sending a comment as a keep-alive every 15 seconds.

- Sec. 6: It looks to me that it is adding some command structure in the Update Stream Service. Does it help to say a few words on why in the bullet item about it in Sec. 3? Initially, I thought we assume a persistent connection setting where the client can continue to turn on and off the update streams by sending multiple requests in the same TCP connection. When reading the 3rd para of Sec. 6.3.2, it is not fully clear. Is it a new connection or the same connection? If a new connection, then due to load balancing, the request may not go to the same ALTO server. 

The stop-updates request is on a new HTTP connection. I will try to make that clearer.

I would have loved to send the stop-updates on the same stream. But I don't think that is compatible with HTTP 1.1. The de-facto convention is that the client sends all its data first, then the server sends its response. While the HTTP 1.1 spec might let us squeak around that, I think most HTTP client libraries and HTTP server frameworks enforce that convention, so a client or server might have to do their own HTTP implementation. That would make it much harder to adopt the extension.

As for a load-balanced server pool, the server which gets the stop-updates request is responsible for forwarding it to the appropriate server. For example, the stream-id could have the id of the specific server. The server which gets stop-updates simply sends a side-channel cease-and-desist order to the server handling the update stream, and then replies to the client. Note that this is a simple reply, not a HTTP redirect or some sort of TCP reconnection.

- Sec. 6.3: a small typo "stop-update" -> "stop-updates" in the third paragraph. Also, it uses a default all semantics. Thinking a bit about it, I tied "ls" under a directory. It shows all. But "rm" says that it is an error. Another piece of thought. I wonder if SSE itself does not have a command structure. 

Fixed the typo.

If you want to follow UNIX conventions, we would
    { "stop-updates": ["*"] }
to stop all updates. But that means a server cannot use * as a resource id (granted, I doubt that will bother anyone). Also, I suspect most users will want to stop all updates. I included the selective-stop for logical completeness.

So I have no problem with an empty array meaning stop-all.

I have not seen anything defining a command structure on top of SSE.


Join to automatically receive all group messages.