This group is locked. No changes can be made to the group while it is locked.
Date
1 - 3 of 3
Revised Incremental Update draft
|
Y. Richard Yang
Wendy, 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. - 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 < - 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. - 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. Thanks. Richard
On Wed, Sep 23, 2015 at 3:10 PM, Wendy Roome <w.roome@...> wrote:
-- ===================================== | Y. Richard Yang <yry@...> | | Professor of Computer Science | =====================================
|
|
|
|
Wendy Roome <w.roome@...>
Richard, Thanks for your comments. My responses in-line.
Yes, I expected that. Do you think it is worth mentioning that in the section?
Because the SSE specification recommends that as a keep-alive. From Section 8:
I will expand Section 4.3 and say that SSE recommends sending a comment as a keep-alive every 15 seconds.
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.
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.
|
|
|
|
Wendy Roome <w.roome@...>
Richard, Revised Incremental Updates draft attached. (Yes, this time I really did attach it). I moved the keep-alive section to a sub-section of Section 6.6. That is a server requirement, so it seems that section is a better fit. - Wendy 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 Wendy, 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. - 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 < - 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. - 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. Thanks. Richard
On Wed, Sep 23, 2015 at 3:10 PM, Wendy Roome <w.roome@...> wrote:
|
|
|