On Apr 8, 2009, at 2:44 PM, Paul Davis wrote:
On Wed, Apr 8, 2009 at 2:15 PM, Devendra Gera <g...@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
