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

[Matt Rogers]

On Sat, Mar 01, 2008 at 11:01:24AM +0100, Tobias Hunger wrote:
> 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

So you basically want to solve the messaging filter problems that we've
already solved in Kopete in Decibel again? I understand that this is a
natural extension, but IMHO, this is something that should be handled by 
the chat application that gets started to handle the message in the
first place. 

If you have these filters, you'll need to handle how to chain them
together so that things are processed in the right order, provide a UI
so that messages that are logged (for example) can be viewed, etc.

You might as well just port the Kopete messaging filtering API to
Decibel, but that's just as bad since both versions will still have to
be maintained, and then we'll get into "Decibel supports this, why
doesn't Kopete?" crap that we already have with the other instant
messengers. Sounds like a nightmare to me.
--
Matt