[Telepathy] Telepathy 1.0 will never happen

[Will Thompson]

On 01/06/11 09:15, Xavier Claessens wrote:
> Le mercredi 01 juin 2011 à 09:46 +0200, Guillaume Desmottes a écrit :
>> Le mardi 31 mai 2011 à 15:22 -0400, Robert McQueen a écrit :
>>>>> Concretely, telepathy-glib would be split into three shared libraries:
>>> ....
>>>> Where would live common types such as, say, TpHandle? Both
>>>> telepathy-glib-dbus-N and tp-glib will use it and tp-glib will have to
>>>> expose it in its public API.

I think making handles disappear entirely is probably the best fix. I
appreciate that they appear in the high-level API for telepathy-glib in
a bunch of places: I haven't looked over how much pain it would be to
hide them everywhere. But generally I would like them to suffer a timely
demise.

> The enums too. I guess the code gen could put all those defines in
> separate headers that could be included in the high-level API. But then
> we again have spec API leaking into high-level API...

The set of constants that concern me more are fully-qualified property
names used in channel requests. I think probably the right answer here
is to not expose request-as-an-a{sv} to applications if possible; and
instead make tp-glib follow in tp-qt4's admirable lead and have
ensureTextChannel()-style methods on accounts and contacts.

That may be a tonne of effort. I think it's inevitable that Empathy (at
least) will have to depend on the -dbus library for a bit.

>> Oh, and we have now TpMessage which is a base class used by CM and
>> clients:
>> http://telepathy.freedesktop.org/doc/telepathy-glib/TpMessage.html#TpMessage.object-hierarchy
> 
> TpMessage is hand-written code, no? I think CMs will use both
> tp-glib-dbus and tp-glib. For all the utilities like tp_asv_, etc.

There's no reason for CMs not to link to the whole lot.

-- 
Will