[Bug 29218] TpStreamTube - high level stream tube API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-08-06 05:09:21 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > I'm not convinced by this channel-view approach. That means that in practice
> > any application will have to create and prepare an extra object per channel
> > when receiving them.
> 
> It was initially a subclass; Danielle, Sjoerd and I argued about this in the
> office for quite some time, and ended up preferring the "view" design.
> 
> The problem with subclassing TpChannel (as is done in telepathy-qt4, for
> instance) is that it makes it harder to have application-specific subclasses.
> If you want to make (say) a MaemoTpChannel with extra stuff bolted on (see
> librtcom-telepathy-glib for motivation), you end up needing to duplicate the
> class hierarchy.
> 
> Because GObject doesn't do multiple inheritance, you'd also end up with
> MaemoTextChannel and MaemoTubeChannel (or whatever) not having a common
> ancestor other than TpChannel (mitigated by the fact that you could give them a
> common GInterface).

Right, that's indeed an issue but I'm not convinced it's worth making the API
more complicate to use for all the "normal" cases.

> > So, why not create subclass of TpChannel for high level API? We could add API
> > to TpBaseClient to say we are interested in those and even API to pass our own
> > factory if we want to create crazy subclass ourself.
> 
> One interesting approach might be to have each place that creates channels
> behind the scenes take a GType as a parameter. If you already know you want
> stream tubes, tell it TP_TYPE_STREAM_TUBE_CHANNEL; if you're handling channels
> in a generic way, TP_TYPE_CHANNEL should be sufficient.

That's what I had in mind when I mentioned adding API to let user tweak the
channel creation.

> (Or, we could define an object or callback that is a channel factory, and use
> that, but that requires that the factory knows about every subclass, which
> makes me sad from a loosely-coupled-objects point of view.)
> 
> TpBaseClient would have to do this via tp_base_client_set_channel_gtype (TpBC
> *, GType), but that's not a problem; subclasses of TpBaseClient could call it
> in constructed(), and TpSimpleHandler etc. could let the caller call it at the
> same time that they add their channel filters.
> 
> Where do we make new channels behind the scenes? At the moment I think it's:

a "git grep tp_channel_new" in telepathy-glib/telepathy-glib seems to confirm
that's indeed the only places where tp-glib creates channels for us.

> * TpBaseClient - easy, add another method as above

Agreed, that seems an elegant solution.

> * TpChannelDispatchOperation when it fetches the Channels D-Bus property - type
> or factory could be passed through from TpBaseClient when using one, but if you
> create a TpChannelDispatchOperation yourself, you're on your own

I don't see any reason why you would want to create a CDO without using
TpBaseClient.

> and we'll soon add:
> 
> * Guillaume's channel-requesting API from Bug #13422, which is secretly a
> TpBaseClient internally
> 
> If we want to go back to subclassing, having weighed up advantages and
> disadvantages, I wonder whether we need the API in Bug #13422 to be
> encapsulated in an object (rather than being a standalone async call), so that
> we have an object on which to tweak "preferences" like which GType you want to
> end up with (without adding a million parameters to the initial async call,
> which doesn't scale).

Very good point.
An object could indeed be a solution (and we could also use it for "re-handle"
notifications so no need of TpHandlerNotifier) but it makes the API more
complicate to use... but I guess we can't win on both sides :\

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.