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 _______________________________________________ Decibel mailing list [email protected] https://mail.kde.org/mailman/listinfo/decibel
