I think it is still is useful to provide a mechanism to gracefully shutdown an update stream. If the client just closes the stream (or crashes), the server keep on sending updates for quite a while before the TCP stack times out. This obviously eats up resources.
But I think it should be considerably simpler than the current draft. So how about this approach: * A server offers one or more update-stream resources. Each such resource provides updates for a set of resources selected by the server. The client request specifies a subset of those resources, and the server responds by pushing updates to the client. This is the only type of request an update-stream resource accepts, so we do not need to call it start-updates or get-updates. * We define another resource type, called close-stream, with a different media-type. The client request is a list of stream-ids for active update-streams. The server responds by closing its end of those streams. A close-stream can close a stream obtained from any update-stream resource. Hence a close-stream resource is not tied to a specific update-stream resource, and a server does not need to offer more than one close-stream resource. I think that is simple & unambiguous. What does everyone think of that modification? - Wendy From: EXT Gao Kai <[email protected]> Date: Wed, March 9, 2016 at 01:05 To: Wendy Roome <[email protected]>, <[email protected]> Subject: Re: [alto] State of the WG On 08/03/16 22:14, Wendy Roome wrote: > A few points: > > * The original proposal did not provide an explicit stop-updates request. > The server just pushed updates until the client closed the stream. Then > after implementing that, I discovered that it took a long time for the > server to discover that the client had closed the stream. That is why I > added stop-updates. At first that was just stop-everything; then it seemed > like a simple extension to allow the client to stop a subset of the > resources. If adding a control interface causes controversy, we could > drop stop-updates altogether. For simplicity, I agree on dropping the stop-updates. And the stream-id is also no longer needed with the removal of control interfaces. >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
