Re: [alto] New Incremental Update draft

[Hans Seidel <[e-mail]>]

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)?

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.

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


On 01.10.2015 17:53, Wendy Roome wrote:
> Hans,
>
> Thanks for pointing that out!  First, I assumed they were exclusive: a 
> request can have start-updates or stop-updates, but not both. But the 
> draft does not say that. My implementation does not support both in 
> one request, but does not return an error if a request does. (My 
> server just ignores the stop-updates field. My culpa!)
>
> But I just realized there is a use for having both in one request. 
> Suppose a client wants to stop a previous update-stream, and replace 
> it with a new stream. Combining both in the same request is more 
> efficient. On the other hand, is that going to happen often enough to 
> matter?
>
> To complicate things, a request with start-updates, stream-id and 
> stop-updates is ambiguous. The stop-updates part is clear. The 
> ambiguity is for the new resources in start-updates. Should the server 
> return updates for those on the new tcp connection? Or should the 
> server add the start-updates resources to the *other* stream - - the 
> one with the stream-id?
>
> I see several ways to fix that:
>
> 1. Say that start-updates & stop-updates are mutually exclusive. That 
> is, a request has start-updates, or stop-updates and stream-id, but no 
> other combination. And say the server must return an error if the 
> client violates that rule.
>
> 2. Allow both in one request. But then we have to decide whether the 
> start-updates resources are to be added to the existing stream, or to 
> be returned in a new stream.
>
> 3. Define two separate requests: start-new-update-stream and 
> modify-existing-update-stream. They would have different parameter 
> types, and hence different accepts media-types. That is unambiguous, 
> and is very general, and would allow a client to add resources to an 
> existing update stream. But that approach is more complicated, and I 
> do not know if the extra complication is worth it.
>
> What do the rest of you think?  My vote is for #1, just to keep it simple.
>
> - Wendy Roome
>
>
> From: Hans Seidel <[e-mail]>
> Date: Thu, October 1, 2015 at 10:45
> To: "Y. Richard Yang" <[e-mail] <mailto:[e-mail]>>, 
> Wendy Roome <[e-mail] 
> <mailto:[e-mail]>>
> Cc: "[e-mail]" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [alto] New Incremental Update draft
>
> Wendy, Richard,
>
> great work.
>
> One question that came up while reading:
>
> 1. Is it allowed to use "start-updates" and "stop-updates" in one HTTP 
> request? I found nothing specific that neither supports nor 
> contradicts that.
>     Intuitively, I would say no, it is not allowed to have both in one 
> request but I am not entirely convinced.
>
> Hans