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

[Eva Brucherseifer]

Hello Matt,

I'd like to ask the other way around:

Would problems have you resolved in kopete and what good code do you have 
around, that you think other applications could benefit of. Just imagine a 
business oriented CRM tool, a whiteboard app, a call center app or even 
koffice with collaboration extension using jabber as communication channel.
I don't want to call kopete "yet another IM client" as it really is a powerful 
tool and has solved many problems. Therefore it makes imho a lot of sense, if 
we don't reimplement things and instead reuse code.

Maybe you see things, that you want to contribute to a central place of 
implementation in decibel instead of maintaining it inside kopete where it is 
only available to kopete. I think the Decibel team really would appreciate 
it!

Eva


Am Samstag, 1. März 2008 schrieb 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
>
> _______________________________________________
> Decibel mailing list
> Decibel at kde.org
> https://mail.kde.org/mailman/listinfo/decibel



-- 
Eva Brucherseifer
Managing Director

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642
eva.brucherseifer at basyskom.de | www.basyskom.de

Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrung: Eva Brucherseifer

Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und 
loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly forbidden.