[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