Re: [alto] New Incremental Update draft

[Wendy Roome <[e-mail]>]

Comments inline.

> From:  Hans Seidel <[e-mail]>
> Date:  Mon, November 2, 2015 at 11:43
> To:  Wendy Roome <[e-mail]>, "Y. Richard Yang"
> <[e-mail]>
> Cc:  "[e-mail]" <[e-mail]>
> 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