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. * 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. * 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 From: EXT Gao Kai <[email protected]> Date: Thu, March 10, 2016 at 21:23 To: Wendy Roome <[email protected]>, <[email protected]> Subject: Re: [alto] State of the WG > I believe your other suggestion is that a client should be able add or remove > resources for an existing stream. Eg, suppose a client creates an update > stream and initially requests updates for the network map and routingcost, but > not hopcount. I believe you would like to allow a client to be able to add > hopcount updates to that existing stream at some later time, without having > to close the stream and create a new one. > > I agree that is a logical extension. But it does complicate the protocol, and > I cannot think of a reason why a client would actually want to do that. Can > you come up with a use case where that helps? One intuitive reason is that if closing a subset of resources is allowed, the symmetric behaviour - starting a subset of resources - (at least for me) should be expected. Consider a p2p client which downloads several files from different peer groups and uses ECS to query the costs between each peer. In the current setting the client must use multiple persistent connections with the ALTO server for incremental updates, which also consumes more resources on both sides than a single connection. Regards, Kai
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
