This group is locked. No changes can be made to the group while it is locked.
Re: Revised Incremental Update draft
Wendy Roome <w.roome@...>
toggle quoted messageShow quoted text
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.
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.
- 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.
On Wed, Sep 23, 2015 at 3:10 PM, Wendy Roome <w.roome@...> wrote: