Bug 27956

Summary: TpBaseClient: should allow to observe invalidated signals
Product: Telepathy Reporter: Guillaume Desmottes <guillaume.desmottes>
Component: tp-glibAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium Keywords: patch
Version: git master   
Hardware: Other   
OS: All   
URL: http://git.collabora.co.uk/?p=user/cassidy/telepathy-glib;a=shortlog;h=refs/heads/observe-invalidated-27956
Whiteboard: review+ with one change
i915 platform: i915 features:

Description Guillaume Desmottes 2010-05-04 03:18:59 UTC
If a channel is invalidated while preparing the ObserveChannelContext we shouldn't fail but pass the invalidated channel to the implementation:
rational: an observer logging missed calls.
Comment 1 Guillaume Desmottes 2010-05-04 03:54:28 UTC
Done in http://git.collabora.co.uk/?p=user/cassidy/telepathy-glib;a=shortlog;h=refs/heads/observe-invalidated-27956

Can you quickly check if it's done the right way so I won't do the same error for the connection.

I guess we should probably do the same for the connection right?
What about the account?
Comment 2 Simon McVittie 2010-05-04 04:02:37 UTC
> +  if (tp_proxy_get_invalidated (source) != NULL)
> +    {
> +      /* Don't discard the channel as the invalidated channel is a valuable
> +       * information for the Observer (to log a missed call for example). */
> +      DEBUG ("Channel has been invalidated");
> +    }
> +  else if (!tp_proxy_prepare_finish (source, result, &error))

This doesn't look right... if preparing failed, it's almost certainly because the channel was invalidated. I think invalidation and failed-preparation should be treated the same - "every channel we're told to observe gets passed to user code" is a much easier guarantee to explain than "every channel we're told to observe gets passed to user code unless it somehow fails without actually being invalidated".

> + *  all having %TP_CHANNEL_FEATURE_CORE prepared if they have not been
> + *  invalidated

"... prepared if possible", perhaps?

> +  g_object_unref (test->text_chan_service);
> +  test->text_chan_service = NULL;

If you want to remove the channel from D-Bus, don't do that by unreffing it (which relies on your reference being the last), but instead by calling tp_dbus_daemon_unregister_object.

And, yes, please do this for the Connection and Account, too.
Comment 3 Simon McVittie 2010-05-04 04:05:28 UTC
(Implementation detail: there's currently no way a Channel can fail to prepare CORE without also being invalidated. The same is true for Connection but not for Account.)
Comment 4 Guillaume Desmottes 2010-05-04 05:46:39 UTC
(In reply to comment #2)
> > +  if (tp_proxy_get_invalidated (source) != NULL)
> > +    {
> > +      /* Don't discard the channel as the invalidated channel is a valuable
> > +       * information for the Observer (to log a missed call for example). */
> > +      DEBUG ("Channel has been invalidated");
> > +    }
> > +  else if (!tp_proxy_prepare_finish (source, result, &error))
> 
> This doesn't look right... if preparing failed, it's almost certainly because
> the channel was invalidated. I think invalidation and failed-preparation should
> be treated the same - "every channel we're told to observe gets passed to user
> code" is a much easier guarantee to explain than "every channel we're told to
> observe gets passed to user code unless it somehow fails without actually being
> invalidated".

How can I check if the context is fully prepared then? There is no API to check if we tried to prepare a feature and it failed.
Any better idea than using a counter for running calls?
Comment 5 Guillaume Desmottes 2010-05-04 06:28:08 UTC
I've redo the branch as it was pretty simple.

http://git.collabora.co.uk/?p=user/cassidy/telepathy-glib;a=shortlog;h=refs/heads/observe-invalidated-27956
Comment 6 Simon McVittie 2010-05-05 05:32:08 UTC
nb is an uncommon abbreviation for number, so I'd prefer nb_pending to be called num_pending. Other than that, this looks fine. Consider that change to have been pre-approved, assuming tests still pass.
Comment 7 Guillaume Desmottes 2010-05-05 05:41:19 UTC
Thanks; merged to master.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.