Re: Proposal for change notifications

[Iago Toral <itoral igalia com>]

On Thu, 20 Jan 2011 14:04:23 +0100, Guillaume Emont <gemont igalia com> 
wrote:
> I was thinking of that in a slightly different way: when will the
> application need notification?
> The only case I can think of where an application might want change
> notification, is if that change concerns something it is currently
> displaying (be it a container it's browsing, or a search/query 
> result).
> I might be biased by my elisa/moovida experience, but in that case, I
> think that was the only notifications we ever needed. I would be
> interested to know of other
> So, how about a mechanism to request notifications along with a 
> search
> or browse?
> Basically, that would mean to add an operation_id to the
> update_notify_add() thing:
>
> guint
> grl_media_source_update_notify_add(GrlSource *source,
> 				guint operation_id,
> 				GrlMediaSourceUpdatedCb callback,
> 				gpointer user_data);
>
> void
> grl_media_source_update_notify_remove(GrlSource *source,
> 				guint notify_id);
>
>
> For the (probably common) case where the back end cannot provide
> "restricted" notification, maybe the core could provide a 
> helper/default
> implementation where it does the filtering of notifications.
> If there are cases that I didn't see where a more generic 
> notification
> "of everything" is needed, the caller can set operation_id to 0.

Probably all this makes sense, at least in theory, since I agree 
clients would (at least in most cases) be interested only in receiving 
notificatons about operations they performed in the past. That said, 
however, I think most backends will not provide support for that kind of 
thing natively, meaning that the actual implementation of this thing 
would be missing in most cases or would have to be done by hand (that 
is, upon notification that something has changed in the service, the 
plugin would have to know what changes these were exactly and check, for 
all registered ops if they would be affected, and then for each one emit 
a notification).

So, even in the case this is doable, and even in the case it is not as 
inefficient as it looks like, I also think we should only switch to that 
kind of thing if the simpler approach is proved insufficient. After all, 
for the client is very easy to ignore a change notification it is not 
interested in, but implementing query-based notifications in all 
plugin/core is far from trivial (and I do not even want to consider the 
case we have filters in the queries :)).

So for me it is more a question of whether the benefits of the fancier 
solution brings is worth the extra complexity and problems derived from 
it, and for now, I think it is not worth it.

Iago