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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #34 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> ---
(In reply to comment #33)
> (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:

Did you forget to push the branch? But yeah go ahead and merge 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.)

Agreed; if anything "should clients use it or just MC" is a good way to split
ifaces I think.

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

Fair enough.

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

I don't really care but I think we have enough in our plate atm to bikeshed on
cosemetic only changes. :)

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