Wendy, 1. That makes perfect sense and thanks for the clarification.
2. Maybe it's just my paranoia but I feel worried about "what if someone squash ADD/REMOVE for the same request-id in one request". May I suggest that we add a statement that this behaviour is undefined and must be avoided? Sorry for my obsession with these details...Thanks! Regards, Kai On 23/03/16 02:10, Wendy Roome wrote: > 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] > <mailto:[email protected]>> > Date: Fri, March 11, 2016 at 23:42 > To: Wendy Roome <[email protected] > <mailto:[email protected]>>, <[email protected] <mailto:[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
