[Bug 29973] TpClientChannelFactory interface and TpDefaultChannelFactory

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-09-03 02:07:39 PDT ---
(In reply to comment #3)
> There is also an option D), which is the same as A) plus, in pseudo-template
> notation:
> 
> list<GQuark> tp_client_channel_factory_get_desired_features (factory);

Then it's up to the user of the factories (TpBaseClient for example) to prepare
the features specified by the factory?


> > I don't like A) because when the user get the channel object I think it should
> > be ready to use.
> 
> ... although TpBaseClient prepares features separately anyway, and it's my main
> target use-case right now.

Good point.

> If we implement A) now, we can easily turn it into B) or D) afterwards, so that
> would be my vote.

Make sense. I started to implement this.

> > B) and C) could work but B) as the small advantage of being usable even when we
> > need an object right away. We can always prepare it later if needed. But I'm
> > not sure what are the use cases for that?
> 
> For a Channel, not a whole lot; for a Connection, since one of the features is
> "become connected", yes we do potentially care about unprepared objects.

Right. Should we have a general interface to create channel and connection
(TpClientFactory?) or define a TpClientConnectionFactory later? An object can
easily implement both interfaces if needed.

Oth, if interfaces defaults to tp_channel_new_from_properties() and
tp_connection_new() we could have a single interface and it won't be an issue
if only one head is actually implemented by the objecT.

I guess the tp-qt4 design is a bit overkill for tp-glib, right?

> (In reply to comment #2)
> > Also, what would do TpDefaultChannelFactory exactly? Only create TpChannel
> > object (no subclass) and prepare TP_CHANNEL_FEATURE_CORE?
> 
> It would be entirely reasonable to have a TpBasicChannelFactory which always
> creates a TpChannel with CORE, and a TpDefaultChannelFactory which creates the
> most-derived subclass in telepathy-glib, and prepares whatever feature is most
> sensible (initially the same as the Basic version, but switching, say, stream
> tubes to be TpStreamTubeChannel would be a compatible change).
> 
> Synonyms for Basic, if you don't like it: Core, Minimal.

I like this idea. TpBasicChannelFactory and TpDefaultChannelFactory sounds good
to me.

> > creating TpStreamTubeChannel objects and preparing
> > TP_CHANNEL_STREAM_TUBE_FEATURE_CORE ?
> 
> This argument matters more for Text channels and preparing GLib equivalents of
> Tp::TextChannel::FeatureMessageQueue (the incoming message queue) and
> Tp::TextChannel::FeatureMessageSending (the outgoing message capabilities),
> which we could consider conflating into one feature.

I think TpDefaultChannelFactory should those features as most client which are
going to handle text channels will propably care.

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