[Bug 49371] [next] rethink what features should be set on TpAutomaticClientFactory

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-05-02 03:33:46 PDT ---
(In reply to comment #0)
> What we are missing is probably a clear definition of what we want there.

IMO: "features that every application understanding the channel type will
want"...

> Note
> that it is super easy for applications to add their own features on the
> factory.

... with this (and the usual principle of "better to be conservative now and
add more guarantees later") meaning that we should err on the side of fewer
features.

> Let's take TpTextChannel and TP_TEXT_CHANNEL_FEATURE_INCOMING_MESSAGES:
>   I think either we think that EVERY app using a TpTextChannel surely needs
> that feature and it should be marked as CORE and so will always be prepared,

Counter-example: an application which sends messages, but delegates to someone
else for receiving. (Admittedly, the MessageSender stuff in MC makes that
unnecessary.)

If we think a feature should always be prepared, then it shouldn't usually be a
separate feature at all, it should just be part of CORE.

I think the only exceptions are for historical reasons -
TpConnectionManager/TpProtocol have a feature that is always attempted but
doesn't always succeed (to support old CMs which only have Parameters and not
Protocols, which is irrelevant in next), and TpChannel has GROUP (as you
already mentioned).

In next, we should get rid of any support for pre-Protocol CMs.

> or
> we think that some app could use TpTextChannel without it and then probably
> automatic client factory shouldn't ask it neither.

Right.

> Note that MC should use
> TpClientFactory (not the automatic) and then won't get a TpTextChannel
> subclass

Indeed. For "MC" read "applications which don't understand specific channel
types", in fact.

> Another example is TP_CHANNEL_FEATURE_GROUP: should it really be CORE of
> TpChannel?

No, it shouldn't. When I made the Group stuff always be prepared (which I think
was before features even existed), it was because I thought Group was going to
remain as important as it was then.

In fact, Group's importance is reducing over time - ContactList channels are no
more, and unlike StreamedMedia, Calls aren't (usually) Groups, so Group
effectively only appears on chatrooms. I've actually wondered whether to
flatten it into Room...

> does MC care about preparing it?

It sort of does, because it uses the equivalent of leave_async() in places, but
again, that's a relic of Group being more important (particularly for calls)
than it is now.

MC/next (when it exists) shouldn't care about Group, IMO.

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