Before actually switching to telepathy-glib 'next' for the Telepathy 1.0 branch, we should get rid of MC's own deprecated stuff.
Created attachment 85553 [details] [review] Break plugin API/ABI
Created attachment 85554 [details] [review] Remove deprecated mcp_dispatch_operation_leave_channels() --- This assumes my most recent patch from Bug #55391, but if that isn't applied, the effect is similar.
Created attachment 85555 [details] [review] Remove partially-implemented McpAccountStorage::altered
Created attachment 85556 [details] [review] Remove deprecated vtable-filling functions
Created attachment 85557 [details] [review] mcp_account_storage_get_restrictions: return the right type
Created attachment 85558 [details] [review] Remove old "D-Bus ACL" plugin API It was last used in Maemo 6. Mainstream Linux doesn't treat the session bus as a security boundary, and if it did, we could do this a lot better (with GAsyncResult, for a start). Also, McpRequestPolicy does this in a much less speculatively-general way.
Created attachment 85559 [details] [review] plugins: use a caller-supplied client factory
Created attachment 85560 [details] [review] service points: do not treat their handles as special Requesting channels by TargetHandle seems rather perverse when we've gone to some length to ensure that identifiers are always at least as available, and in particular, if the user of a Telepathy-based phone or something types 911 into a keypad, the request is going to be TargetID-based. telepathy-spec 1.0 should specify this. --- Still to be done: a spec patch for that. That's all for now.
My proposal is currently to do this as the beginning of the 'next' branch, but I'd be OK with doing this on master if people think it's fine. We'll break plugin API/ABI again *anyway* when we move to 1.0.
Comment on attachment 85553 [details] [review] Break plugin API/ABI Review of attachment 85553 [details] [review]: ----------------------------------------------------------------- Looks good. Who is using this API these days? Empathy's GOA and UOA plugins?
Comment on attachment 85554 [details] [review] Remove deprecated mcp_dispatch_operation_leave_channels() Review of attachment 85554 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85555 [details] [review] Remove partially-implemented McpAccountStorage::altered Review of attachment 85555 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85556 [details] [review] Remove deprecated vtable-filling functions Review of attachment 85556 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85557 [details] [review] mcp_account_storage_get_restrictions: return the right type Review of attachment 85557 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85558 [details] [review] Remove old "D-Bus ACL" plugin API Review of attachment 85558 [details] [review]: ----------------------------------------------------------------- Yeah for code deletion! ++
Comment on attachment 85559 [details] [review] plugins: use a caller-supplied client factory Review of attachment 85559 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85560 [details] [review] service points: do not treat their handles as special Review of attachment 85560 [details] [review]: ----------------------------------------------------------------- ++ Did you patch the 1.0 spec already?
(In reply to comment #10) > Looks good. Who is using this API these days? Empathy's GOA and UOA plugins? telepathy-ring also ships a plugin (at least in the heavily-patched version in Nemo, which is probably the de facto upstream these days): <https://github.com/nemomobile/telepathy-ring/tree/master/mc-plugin>.
(In reply to comment #9) > My proposal is currently to do this as the beginning of the 'next' branch, > but I'd be OK with doing this on master if people think it's fine. Which would you prefer? (In reply to comment #17) > Did you patch the 1.0 spec already? Not yet.
(In reply to comment #19) > (In reply to comment #9) > > My proposal is currently to do this as the beginning of the 'next' branch, > > but I'd be OK with doing this on master if people think it's fine. > > Which would you prefer? If porting Empathy's plugins is trivial I don't really really care tbh.
(In reply to comment #20) > > > My proposal is currently to do this as the beginning of the 'next' branch, > > > but I'd be OK with doing this on master if people think it's fine. > > > > Which would you prefer? > > If porting Empathy's plugins is trivial I don't really really care tbh. It turned out to be trivial, so this is in git for 5.17.0 (which might actually never happen, if next goes well). (In reply to comment #17) > Did you patch the 1.0 spec already? Not yet (so I'm going to leave this open as a reminder). I'm wondering whether we can just forbid request-by-handle, and require TargetID in all requests that have a nonzero TargetHandleType (possibly renamed to TargetType but that might be a sed too far).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/74.
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.