Re: Proposal for change notifications

["Juan A." Suárez Romero <jasuarez igalia com>]

On Wed, 2011-01-19 at 13:01 +0100, Iago Toral Quiroga wrote:
> > typedef void
> > (*GrlMediaSourceUpdatedCb) (GrlMediaSource *source,
> > 			GrlMedia *media,
> > 			GrlMediaSourceUpdatedType type,
> > 			gboolean include_children,
> > 			gpointer user_data);
> > 
> > 
> > "media" is the media that has changed. Usually, it will be a GrlBox,
> > meaning that content in that box has changed. But I keep the more
> > generic GrlMedia just in case a plugin has the ability to specifically
> > notifiy that a media has changed.
> 
> I have some doubts here. Let's discuss this proposal over a specific
> example: let's say I copy a new file and Tracker indexes it. The plugin
> would invoke the notify callback with the parent folder... but what is
> that parent folder? for sources that do not implement browse, this does
> not even make sense! We could be interested in notify signals even if
> the source is only searchable, right?

If the direct parent folder can be obtained, then the root one should be
used, and include_children set to True. IMHO, if the source doesn't
implement browse() it should always use this approach, even if it knows
to compute a parent box for the changed elements, because we do not
support search in specific folder.

If I, as application developer, are only interested in results obtained
with a search, everytime I get a notification, if media is a GrlBox[1],
no matter if it is a root or any other folder, or the value of
include_children: I will perform a new search.

The value of the box and include_children is only interested for the
cases where a browse is supported: I need to know if a new browse must
be done or not.


> > "include_children" means that the media, or any of its descendants, have
> > changed. Of course, it only means in the (standard) case of using a
> > GrlBox as media.
> > 
> > If include_children==FALSE, it means that the box content (the direct
> > children) have changed. But if include_children==True then any of the
> > direct or indirect (children, grand-children, ...) have changed.
> > 
> > Thus, in the case that a plugin is only able to notify that a changed
> > happened in the pugin, but not where, then it can use the root box as
> > media, and include_children==True, meaning that "something in the root
> > or below has changed".
> 
> The idea looks good to me, but I dislike the 'include_children' name.
> What about 'change_location_unknown'? Also, again, we chould check how
> this works with searchable-only plugins.

To be honest, I didn't like it very much :) But I couldn't get a better
name.

I'd use 'location_unknown', shorter, and we already know we are talking
about changes.

Regarding searchable-only plugins, I would use in that case the root
GrlBox and location_unknown==True. Which means 'something changed in the
plugin'.

> 
> > "type" indicates the kind of change. Currently, I'm only thinking on
> > having 3 different values:
> > 
> >   * GRL_UPDATE_ADDED
> >   * GRL_UPDATE_REMOVED
> >   * GRL_UPDATE_CHANGED
> > 
> > When something has been added and removed at the same time, the last
> > value would be used.
> 
> I guess you mean "when various items have been added / removed", the
> last value would be used.

Yes. Or if plugin knows there was a change, but not the kind of change,
it would also use GRL_UPDATE_CHANGED.

> 
> What about the case of a signle media file that has been updated? (for
> example its metadata has been changed). Would we use CHANGED for this
> case too?
> 

Yes, I would use it too.

> > I'm not very sure if we actually need this "type" value. I've proposed
> > it because I was also contemplating a new kind of update: when a source
> > is being updated. This happens, for instance, when Tracker is updating
> > the content, or if a Podcasts plugin is downloading the latest clips. In
> > this case, a GRL_UPDATED_UPDATING signal can be used to tell it is being
> > updated.
> 
> Yeah, probably when a source is being updated it should wait until it
> has finished before signaling anything. In that case it could emit a
> bunch of ADDED / REMOVED notifications or just a single CHANGED.
> 

Yes, I would emit first the GRL_UPDATE_UPDATING and finally
GRL_UPDATE_CHANGED to notify user that something changed.

We need to take in care that a change can happen in a file without
actually changing its properties. Even in this case a notification
should be emitted. But I'm not sure if it would be worth to have a
different change flag to notify that though it has changed, no need to
perform a new browse() nor metadata() is required, because properties
have not changed. I would forget about it right now.


       J.A.


[1] I say a GrlBox, because if it is a GrlMedia and plugin supports
metadata() operation, I just need to redo the metadata(). Otherwise, I
would need to do the search again.