[Bug 29973] TpClientChannelFactory interface and TpDefaultChannelFactory

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |danielle.madeley at collabora.
                   |                            |co.uk,
                   |                            |olli.salli at collabora.co.uk
             Blocks|                            |29451

--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-02 10:15:18 PDT ---
See also Bug #29451 for general discussion on this topic. Adding Olli to cc
here because he's largely been driving the design in Qt-land.

(In reply to comment #1)

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);

(where list could mean GArray or 0-terminated-C-array or something)

> 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.

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

The denizens of #introspection tell me that increasing the size of a GInterface
is considered to be a compatible change, so we can always add more methods, as
long as there is something sensible that can be done if an implementation of
the interface has no implementation for the method. A prepare_async method's
default implementation could just be "succeed in an idle" or "prepare the core
feature", and a get_desired_features method could just return the core feature,
for instance.

(Olli: FYI, prepare_async is telepathy-glib's equivalent of becomeReady.)

> 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.

(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.

Synonyms for Default, if you don't like that (or if Basic might in fact be the
default): Normal, Conventional, Automatic.

This would avoid potential layering problems where the channel factory must
"know about" every TpChannel subclass in telepathy-glib, by putting the
GInterface at a layer just above TpChannel itself, but the default
implementation at a layer much higher than that (above all the subclasses).

> 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.

It's not actually very relevant for stream tubes, since I think Danielle
intended for stream tubes to be somewhat stateless, and for Offer() and
Accept() to be orthogonal async methods which are not features (they have
side-effects and need extra information, so they can't usefully be features,
AIUI). If someone other than the handler has changed the stream tube's state
then (a) they're wrong, and (b) the async methods will just fail (which should
probably invalidate the channel as a side-effect, since it's no longer useful).

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