[Bug 69430] Make NewChannels, etc., singular?

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jan 15 04:30:35 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=69430

--- Comment #33 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #18)
> (In reply to comment #16)
> > Comment on attachment 88630 [details]
> > [02/12] Flatten Requests interface into Connection
> > 
> > Obsoleted by Bug #71262
> 
> ... er, Bug #50093

Sorry, please revert this one (I've put a suggested patch in smcv/next). I
decided against it:

(In reply to comment #14)
> This might actually not be such a great idea. EnsureChannel and
> CreateChannel should clearly be core, and RequestableChannelClasses (aka
> TP_CONNECTION_FEATURE_CAPABILITIES) can reasonably be core while connected,
> but Channels (and its change-notification, NewChannel(s) and ChannelClosed)
> are sufficiently special-purpose that I think only the AM and regression
> tests should be using it. Having the Channels and their immutable properties
> in the GetAll result seems non-optimal.
> 
> I'm tempted to revise this plan to:
> 
> * move EnsureChannel, CreateChannel, RequestableChannelClasses to Connection
> 
> * rename the rest of Requests to ChannelList
> 
> * keep ChannelList mandatory

Your call whether to move EnsureChannel, CreateChannel to Connection. On
balance it's probably not a good idea. (Rationale: we only expect MC to use
them.)

Moving RequestableChannelClasses is probably still a good idea; I haven't done
it. (Rationale: we expect non-MC things to use it.)

Renaming Requests to ChannelList is entirely cosmetic, and would even be
misleading if we leave EnsureChannel, CreateChannel on that interface, so let's
not.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the telepathy-bugs mailing list