On 11/03/16 04:23, Wendy Roome wrote: > Kai, > > Thanks for continuing the discussion. I’ll summarize what I think you > are proposing; please correct me if I misunderstood you. > > First, I think you would prefer that an ALTO server offer a single > update-stream resource, which handles updates for all resources, > rather than allowing a server to define N different update stream > resources, each of which handles a different subset of resources. > > I think most servers will provide a single update-stream resource. I > think that is the simplest approach, and I would be happy to recommend > that. But I do not think we should require that. For one thing, we > haven’t done that for other services. E.g., suppose a server provides > ECS for 4 cost types. A server can offer one ECS resource for all 4 > cost types, and most servers will do that. But we did not require > that; a server can offer 4 different ECS resources, with one cost type > each, if the server wants. > > Also, suppose an ALTO server has two different network maps: one is > public, and available to everyone, while the other is private, and > only available to authorized users. The private network map & cost > maps use https and require a client certificate. In this case the > server needs two separate update stream resources: a public one for > updates to the public maps, and a private one, which also requires a > client certificate, for updates to the private maps. > Actually I have no problem with multiple update-stream resources. Instead I would like to allow a server to have multiple ones as you suggested.
> 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 > > - Wendy Roome > > From: EXT Gao Kai <[email protected] > <mailto:[email protected]>> > Date: Thu, March 10, 2016 at 05:37 > To: Wendy Roome <[email protected] > <mailto:[email protected]>>, <[email protected] <mailto:[email protected]>> > Subject: Re: [alto] State of the WG > > Here is how I think of pushing updates for multiple resources in one > stream and also explains why I'm not comfortable with the current design. > > 1. Can multiple resources be put in one stream? > Yes -> 2 > NO -> I can live with this. But as Wendy suggested, we still want to > make it easier for clients to handle dependencies. > > 2. Can arbitrary resources be put in one stream? > Yes/NO -> 3 > NO -> What's the principle here then? At the moment dependency (not > necessarily the binding of network map and cost map but it's the only > dependency defined by now) is the only principle that makes sense. > > 3. Do we allow closing a subset of resources in a stream? > Yes -> 4 > NO -> I can live with this. > > 4. Can a client add resources to a stream then? > Yes -> That's what I prefer because if we support closing a subset, it > seems reasonable and natural to have the symmetric operation. But we > might have to extend the protocol. > NO -> That's where we are and it really doesn't make any sense to me. > > Regards, > Kai
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
