On 5/8/09 2:15 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:

> There is no gap in time if you put the new watch into the call that gives
> you the current version of the data.  That is the point of having the watch
> argument in all of the get* calls!
> 

There is a gap in time between when watch A triggers, and when the server
gets your next watch setting.  From both the server and client point of
view, the watch "ends" when it fires, and there is a gap in time before the
next one begins.
Changes between those times must be inferred by the client.

A node might exist and be deleted many times between processing an exists
watch and the server getting your next watch.  Although getting an event
each time that happens is not preferable, knowing that something did happen
would be useful.

Why do I think this feature is needed?  Because it removes a common use case
boilerplate pattern and simplifies it.

The discussion in this thread was about how if you want to keep watching a
node, you have to re-register a watch and infer the possible changes on your
own.  A persistent watch would **do that for you**.
An advanced one with some server side assistance wouldn't have to send the
whole boatload of data (like the 1000 children example here) on every
update, but could just get a 'diff' each round-trip.




> On Fri, May 8, 2009 at 1:43 PM, Scott Carey <sc...@richrelevance.com> wrote:
> 
>> This type of watch would stick around, and doesn't have the gap-in-time
>> problem that the other watchers do.  This is particularly useful for exists
>> and children -- less so for data.
>> 
> 

Reply via email to