Kai, 1. The Create-Stream request must be POST, not GET. The ALTO server doesn¹t care, but the HTTP protocol allows proxies to cache GET requests. Proxies are not supposed to cache POST requests.
2. The control commands I defined don¹t really interact with each other, so I don¹t think we need to define a processing order, other than to say that the server should not close the stream unless there are no resources left after all commands have been processed. Oh yes, SHUTDOWN should be the only command in a request; there is no point in combining SHUTDOWN with anything else. Does everyone like this alternative? If so, I will update the draft. - Wendy From: EXT Gao Kai <[email protected]> Date: Fri, March 11, 2016 at 23:42 To: Wendy Roome <[email protected]>, <[email protected]> Subject: Re: [alto] State of the WG I like the new proposal. Please see the inline comments. On 12/03/16 02:38, Wendy Roome wrote: > Thanks! Okay, I will outline a way to allow that. This uses the same basic > structure as the current proposal, but changes the plumbing around a bit. > > * As in the current draft, the server defines one or more Update-Stream > resources, each of which covers a set of resource ids. > > * To create an update stream, a client sends a Post request to an > Update-Stream resource. However, the client does NOT send any data with the > request. Is it possible to use GET if no input is required? Or is POST used here to allow future extensions? > > * The server responds by sending an SSE event with a uri of a Stream Control > Resource. The client can send POST requests to that uri to control this Update > Stream. The uri would presumably contain an unique identifier for this stream, > but the mechanism is not specified. > > * A client can send ADD, REMOVE, and SHUTDOWN commands on a Stream Control > resource. The client can send several commands in a single POST request. Maybe we should set up some rules here for processing the commands to prevent arbitrary behaviours. For example, some implementation might process the commands in order but others may not; some preserve the transaction semantic but others may not. > > * An ADD command tells the server to send update events for a new resource. > The command includes: > > + A unique request-id, chosen by the client (this is new). > + The resource-id of the ALTO resource for which the client wants updates. > + A boolean flag indicating whether the client will accept incremental > updates. > + If resource-id is a tagged resource, the tag of the client's current > version. > + If resource-id is POST-mode, the parameters for that request. > > * The server includes the request-id in each SSE update event. This allows a > client use one Update Stream to get updates for several different ECS requests > (the original proposal did not allow that). > > * A client should send one or more ADD commands immediately after receiving > the Stream Control URI from the server. If not, the server will close the > stream. > > * A REMOVE command tells the server to stop sending updates for a previously > added resource. The command gives the request id. The server closes the stream > when the client removes the last request. > > * For convenience, SHUTDOWN stops all updates and closes the stream. > > * We might require a client to send a keep-alive request on the Control > resource every (say) 5 or 10 minutes, just to ensure the client is still > alive. > > How do folks feel about this revision? It¹s different, but I don¹t think it¹s > any more complicated, or harder to implement & use, than the current proposal. > > - Wendy Roome >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
