couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Document update notifications
Date Wed, 08 Apr 2009 21:28:22 GMT

On Apr 8, 2009, at 2:44 PM, Paul Davis wrote:

> On Wed, Apr 8, 2009 at 2:15 PM, Devendra Gera <gera@theoldmonk.net>  
> wrote:
>> Hi Paul,
>>
>> Thanks for taking the time to review the patch.
>>
>> On Wed, 08 Apr 2009, Paul Davis wrote:
>>
>>> Gera,
>>>
>>> That looks like a solid patch, but unfortunately I think that the
>>> comet notification will end up superseding the functionality. The
>>> basic ideas of the comet framework are to post a JavaScript function
>>> to the server to allow clients to filter db updates. I'm pretty sure
>>> this is under active development so stay tuned for updates.
>>
>> Would the comet notifications supersede the (currently implemented)  
>> db
>> update notifications as well? Are there any estimates as to when that
>> would come around.
>>
>
> Pretty sure the idea is to replace the current system's functionality.
> I'm not sure if that means update_notification will go away or not,
> but from what I gather on the expected use cases it'll be a "new code
> should use comet" type of situation. As far as estimates, I'm not
> sure. I don't have too much knowledge on the current status, just that
> there was work being done on some necessary bits. Keep an eye on dev@
> and you'll be up to date as things start building up.

I'm working on it and even I can't say when :) Too much stuff pops up  
that's out of my control, so I don't give completion estimates any more.

But I will say it's my highest priority development task right now.

>
>> I guess, what I'm trying to ask is that does the patch make sense  
>> as in
>> interim solution?
>>
>
> If you mean in trunk, I'm not sure but I doubt it. If for no other
> reason than if we added such a feature to trunk it'd be a signal that
> we intend to support it for a very long time when we're already acting
> on plans to replace it.
>
>> If not, we'll just keep using the patch internally (and offer it
>> out-of-tree) while waiting for the superseding functionality.

I'd keep using you patch until the new API lands. The new way will be  
more robust and far more flexible. The old way will stay around for a  
while, but will likely be removed before 1.0.

-Damien

Mime
View raw message