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 <[email protected]>
Date: Thu, October 1, 2015 at 10:45
To: "Y. Richard Yang" <[email protected] <mailto:[email protected]>>,
Wendy Roome <[email protected]
<mailto:[email protected]>>
Cc: "[email protected]" <[email protected] <mailto:[email protected]>>
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
