[Decibel] Fwd: Summer of Code 2008 - Call For Ideas

[Tobias Hunger]

On Friday 29 February 2008, Matt Rogers wrote:
> On Fri, Feb 29, 2008 at 03:01:45PM +0100, Eva Brucherseifer wrote:
> The filtering framework project doesn't make sense as something to have
> in Decibel. IIUC, Decibel is not an IM client and therefore it shouldn't
> have a filtering framework. The filtering frameworks should be left up
> to the IM clients that are using the decibel components, IMO.
>
> Since I see Decibel as more of an API (like Solid, or Phonon), I think I
> need some clarification as to exactly where people think Decibel will be
> going.

Let me go back a bit:

We are using Telepathy in the backend. That is a D-Bus api that splits all the 
protocol handling code into separate processes and makes it available to all 
telepathy aware apps (with the additional bonus of not crashing the gui when 
the protocol backend fails;-).

Decibel tries to drive this further: It encapsulates functionality 
traditionally found in a communication application and moves it into a 
separate process, the decibel daemon. That daemon manages user accounts and 
brings them online/offline as required. It updates presence state of 
contacts. It listens to incoming communication requests and decides what to 
do with them.

Currently the last part is implemented as asking a list of applications (which 
can be configured based on protocol used in the request, contacts and 
accounts involved, etc.) whether they want to handle a communication channel. 
The first one to do so gets the channel, while those that rejected the 
channel can still receive messages about updates to the channel. That way you 
can have a logger as one of the first applications configured as handler for 
e.g. text chat. It will reject the channel after having subscribed to 
the "new message signal" of the text channel. Then Decibel will continue to 
look for another suitable application to launch, e.g. a text chat 
application. That will accept the channel and the Decibel daemon is happy 
that it found a suitable handler and stop.

Filtering of channels (at least text messages, streams like VoIP, etc. are 
passed outside of D-Bus and are thus not applicable for this kind of 
processing) is a natural extension of the already existing functionality and 
the way telepathy works. It increases code reuse as each module can get used 
independent of chat application.

I hope this sheds a bit of light on the issue,

Best Regards,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/decibel/attachments/20080301/72f22d53/attachment.pgp