Comments inline. > From: Hans Seidel <[email protected]> > Date: Mon, November 2, 2015 at 11:43 > To: Wendy Roome <[email protected]>, "Y. Richard Yang" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [alto] New Incremental Update draft > > Wendy, > > while working on our Incremental Update implementation is was thinking about > the 3 solutions and decided to prefer option 1. I also like it for its > simplicity while it still keeps start and stop separated. > However,if I read your mail correctly the stream-id field is only allowed in > stop updates. That means adding resources to an existing stream is not > supported. So, if a client wants to add resources it needs to create a new > stream requesting the existing + the new resource(s)?
That is my suggestion. Adding resources to an existing stream is messy. And it creates a new class of ambiguity. Eg, suppose creates a update stream for changes to an ECS query. Then suppose the client modifies the stream by adding another ECS query. Update events are tagged with the ECS resource id - - which is the same. So does the added ECS query replace the previous one? Or should the server merge the query somehow? Or flag it as an error?? I suggest revising the request Update Stream request syntax slightly. The client request has only one top-level field, start-updates or stop-updates. start-updates is as before. stop-updates is an object with two fields, stream-id and resources. stream-id is a string, and resources is an array of ids of resources to stop. If resources is empty or omitted, stop all resources. That makes it clear that a client cannot add a resource to an existing stream. > > Furthermore, I updated our ALTO server (alto.benocs.berlin:8000/directory) and > it now supports the incremental-updates draft -01. However, since we use the > interop network to generate the maps > there are no changes (yet). Hence, every client will only receive the start > event and the first resource data but no updates since there aren't any > changes in the network. When I tried your server I immediately get EOF on the stream. However, I did that from work, where I have to go through a very strict (and probably ancient) proxy, and the proxy might not handle SSE. I will try tonight from home. > > Due to the lack of updates from our ALTO server I was also thinking about > adding some (optional) incremental update tests to the interop draft. What do > you think? > > Hans Yes, we would need that if we want the interop test to be a permanent feature. Quick idea: define a new set of network specifications. Say one network map and associated cost maps. Define several different cost maps, which differ by a few cost points. The server would randomly switch between those maps. The client would verify that the map is always one of the valid one. And define two different versions of the network map. Same PID names, but one or two CIDRs flip from one PID to another in the two maps. The server would also alternate between those two network maps. - Wendy Roome
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
