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.
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?
> + 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.
(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.)
(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?
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
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.
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.