Re: Proposal for change notifications

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

On Thu, 2011-01-20 at 07:13 +0000, Iago Toral wrote:
>  Basically, connecting to signals is the very same thing, in the end
> you 
>  use a function (g_signal_connect) to register a callback. However,
> you 
>  get the extra benefit of having the whole GSignal API at your
> disposal, 
>  and this is a good pro. The only benefit I see in having our own 
>  subscription mechanism is that we can check if the plugin actually 
>  supports the operation at the moment it attempts to register a
> callback, 
>  but that sounds too weak to discard gsignal.
> 
>  Also, I think we should go with the callbacks or gsignal, but not
> both 
>  as you suggested we may have in the future. Having two ways of doing
> the 
>  same thing is just a waste of time and an unnecessary complication. 


Yeah, you're right. Actually, I've been thinking more about it, and what
I would do is to use GSignals to implement it.

But I would add grl_media_source_notify_start/stop() functions.

Why? Because in most plugins notifying about changes would require to do
some extra effort, and it doesn't make sense if nobody is interested in
the changes.

Thus, grl_media_source_notify_start() would be implemented by the
sources that support change notification. They can start all the stuff
required to send notifications, and notifications would send through
signals.

In the same way, grl_media_source_notify_stop() would stop it, freeing
all resources and time required to do the notifications.

Clients would execute grl_media_source_notify_start() to start
notifications and then use the typical GSignals to connect to the
changes.

	J.A.