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

[Matt Rogers]

On Monday 03 March 2008 11:28:34 Eva Brucherseifer wrote:
> 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.
>

Thank you for providing some use-cases that would make sense for this feature. 
I withdraw my original objections.

> 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
>

Can you provide me with extra hours in my day? :)
--
Matt

> 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