[Decibel] Decibel and the Telepathy Spec - into the future...

[George Goldberg]

Hi all,

I've been thinking a lot over the last few months about how to move
forward with Decibel, and now with the Christmas holidays approaching,
I think its time to start getting an idea about what could actually be
turned into code. This email is a bit of a braindump to gather the
mood a bit from other contributors to where we are going, so please
understand that some of the ideas I write down on here may be
completely crazy, or simply factually incorrect - ie please don't
flame me if you disagree. I haven't made my own mind up on how to
proceed just yet either.

1) telepathy-qt bindings

At the moment we have got telepathy-qt and tapioca-qt in kdesupport
svn, both of which Decibel depends on. They work, but only just - I
stripped out support for anything other than text channels just to get
them working last summer. Since then they have remained basically
untouched, so I feel confident saying they are unmaintained.
telepathy-qt also has the added problem that every tiny little change
the telepathy SPEC people make breaks its binary compatability, and
since they change it about once every 2 minutes, this makes them as
good as impossible to work with.

So, how do we fix this?

In my opinion, we should switch Decibel to use the new telepathyQt4
bindings, which although incomplete, are coming on very rapidly. This
doesn't necessitate any change to the Decibel API apart from replacing
things like QtTapioca::Channel with Teleapthy::Channel - ie no major
restructuring. That way we don't have to worry about maintaining our
own bindings, which, unless someone steps up to do, I simply don't
have time for.

Assuming that there are no objections to this, I would like to start
making this change over the Christmas period - in reality probably
early January. I would do this in a branch so that it won't break
Decibel, and by extension kdesupport while in progress.

2) Differences between Decibel API's and Telepathy SPEC API's.

This section is far more hypothetical than the previous - I'm really
not sure what is the right approach at the moment, but I'll attempt to
put some ideas on the table and see what people make of them.

One thing that occurred to me that might be good is to break up
Decibel into separate modules in their own processes - at this stage
that basically just means making the AccountManager a standalone
process rather than an in-process plugin as it is at the moment.

It might also be an idea to implement the now stable (I think)
AccountManager API from the telepathy SPEC alongside the existing API
that decibel uses. That would allow empathy and other existing
telepathy GUI's to run in a KDE environment (which I think would be
useful since there are currently no KDE GUI's for telepathy), whilst
keeping the account data in KDE specific storage so that a future KDE
telepathy GUI could take over them. (Empathy would of course still
require mission control to run, but would at least have the account
data stored in KDE land).

Ideas? Opinions? Am I on crack?

George