Bug 42095 - Drop support for legacy interfaces where it does not break ABI
Summary: Drop support for legacy interfaces where it does not break ABI
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.com/git/user/xc...
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-10-21 09:53 UTC by Xavier Claessens
Modified: 2011-12-14 02:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Xavier Claessens 2011-10-21 09:53:02 UTC
We have lots of fallback code that none of our CMs needs anymore. For example contact attributes and dbus properties should be mandatory everywhere now IMO.

Since we released 0.16.0 stable branch, now is a good time to remove a bit of legacy code and raise the minimum expected from our CMs, IMO. That would make this more maintainable, I think.
Comment 1 Xavier Claessens 2011-10-21 09:54:00 UTC
Here is a branch already removing ~3500 lines of code:

http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=cleanup
Comment 2 Xavier Claessens 2011-10-21 09:56:52 UTC
Could also remove fallback in TpChannel and make properties mandatory there. But there were recent spec changes there that are not yet in tp-python...
Comment 3 Xavier Claessens 2011-12-01 05:42:52 UTC
The branch now makes properties mandatory for CORE and GROUP features of TpChannel. It also makes MembersChangedDetailed mandatory (otherwise, TpChannel fails to prepare). Those are supported by all CMs as far as I know.

I'm pondering making TpConnection fail to prepare if it does not have immortal handles, but that would make definitely break python CMs, right?
Comment 4 Xavier Claessens 2011-12-01 07:25:26 UTC
(In reply to comment #3)
> I'm pondering making TpConnection fail to prepare if it does not have immortal
> handles, but that would make definitely break python CMs, right?

Now done
Comment 5 Jonny Lamb 2011-12-13 04:30:00 UTC
+ if (!tp_proxy_has_interface_by_id (context->connection,
+ TP_IFACE_QUARK_CONNECTION_INTERFACE_CONTACTS))
+ {
+ GError *error = g_error_new_literal (TP_ERRORS,
+ TP_ERROR_SOFTWARE_UPGRADE_REQUIRED,
+ "Connection does not implement CONTACTS interface. Legacy CM "
+ "are not supported anymore");
+
+ WARNING ("%s", error->message);
+ contacts_context_fail (context, error);
+ g_clear_error (&error);
+ }


(Thanks Firefox or whoever for removing indentation.)

Should this not return from the function after g_clear_error?

Also, "CMs" please.

  PROP_ACCOUNT = 1,
- PROP_BREAK_PROPS = 2,
  PROP_DBUS_STATUS = 3,
  N_PROPS

Probably not a problem, but still.

+ * return FALSE will invalidate the proxy. */

"returning FALSE" (sorry for the nit-pick)

Other than these, this branch looks fine. I assume the tests all pass again given your work on them?

I'm just thinking about where this branch should end up, master or next.
Comment 6 Xavier Claessens 2011-12-13 05:43:24 UTC
Fixed all comments, rebased on master, and unit tests still pass.

master or next is a good question though.
Comment 7 Xavier Claessens 2011-12-14 02:28:31 UTC
Branch merged into next.


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.