Le March 14, 2007 16:33, Will Stephenson a écrit : > On Tuesday 13 March 2007 22:43:24 Michaël Larouche wrote: > > I have written a small list of things that I think shall be done at least > > for Kopete 1.0. This is just a proposal and I'm asking your input on this > > matter :)
> > # Make use of the Command/Job pattern for most contact management task
> > and all other tasks.
> >
> > I think we could keep that point in mind when refactoring the contact
> > list handling. I have notified some tasks that could really use this
> > pattern. Like deleting a contact. I have no way to be notified if the
> > deletion of a contact went wrong. Most of the contacts tasks are
> > implemented as method of some classes, like
> > Kopete::Contact::deleteContact which return.....void.
> >
> > Using the Command pattern allow us to use signals for notification and
> > encapsulate tasks into proper object. One task, one object. Easier to
> > maintain too.
>
> Full ack, we have had this for years with Kopete::Task but we have not used
> it widely and never outside of libkopete. Instead we've still got our own
> implementations of the Command pattern in each protocol. If you take a
> step back from Kopete and think about this, it makes no sense. We've got
> enough experience now to factor a lot of infrastructure out of the
> protocols and into libkopete. Which leads to
The pattern used in Kopete::Task (which is more like KJob) and used in
protocol Task have notable differences.
The protocol Task root also route transfer along its childens and create
transfers too, which is a complete different job that Kopete::Task
Kopete::Task is more closer to the Command pattern than Protocol::Task
> > - Separate libkopete into libkopete_protocols and libkopete_app (of
> > course with better name)
> >
> > Why we should split libkopete ? Because some code in libkopete are
> > related to the application itself (and plugins) and others are related to
> > protocol implementation. If we want to be more efficient and have a core
> > library more easy to maintain, I think we should split the library which
> > has two distinct missions, manage the application and help to implement
> > the protocol.
>
> Exactly, a libkopete_protocols and libkopete_core split will make both more
> manageable.
Good :) As a said on IRC, I suggest that libkopete_protocols should be Qt-only
to remove a unneeded dependency on kdelibs.
Qt, and to a extend QCA, contains everything we need for protocol
implementation and thus I see no reason why it should depend on kdelibs and
anyway, with the Telepathy abstraction, we don't have to deal with those
protocols directly anymore.
Also, at first, my goal with libpapillon was to be complety independent but I
decided I could change my mind and share the common classes with our own
developed protocols, i.e not libiris which is external to us. Some basic
subsystem need to be cleaned and refactored like the Connector and Stream
model.
in fact, only libkyahoo use kdelibs and its usage of kdelibs can be replaced
with a bit of effort. It's using KIO for http with can be replaced. I have
some HTTP bits in libpapillon for example
> > The general consensus of everyone was Kopete will going to move to full
> > Telepathy support in a near future.
>
> +1
>
> > But currently Telepathy spec and Decibel are not mature enough to our
>
> needs.
>
> I am not sure that this is true. Telepathy, as the bit that defines how to
> talk to a connection manager ('CM', ~= Kopete::Protocol) is pretty good.
> And Decibel is maturing very quickly, and is malleable to our needs. With
> the amount of redesign needed in libkopete and kopete, would it not make
> sense to merge much of a redesigned libkopete_core into the Decibel daemon?
> And keep the kopete frontend as an interface to Decibel.
>
> The alternative is that we let Kopete use CMs as well as native protocols,
> but for KDE integration this is suboptimal, then we have duplication of
> function between libkopete and the Decibel daemon and apps probably use
> Decibel for IM services, we end up with both running at the same time
> knocking each other's accounts offline, it's ugly.
>
> Quick sketch
>
> [ Kopete UI ] [ Other KDE apps ]
>
> [ Decibel/libkopete daemon ] - [ Akonadi ]
>
> [ Kopete derived CMs ] [ foreign CMs ]
I agree that we should avoid duplication of code, running memory and effort
with Decibel. Again it need a lot of work and thus a lot of time, refering to
my first point in the initial email.
The major showstopper in Telepathy is lack of support for file transfer, which
is being worked on. Sure we will always users that will want implementation
of specific features of protocols like "Hey I want my custom emoticons or
check my mail in Hotmail etc." Well you are aware just as me of users need
about protocol features.
> > But we need to prepare for that
> > move, because most people want to keep a BC during Kopete 1.0 period.
>
> I think BC should come in with 4.1 at the soonest. BC for Kopete in KDE 3
> has not brought us much, and we have big changes to do.
>
> > # Make framework ready to Decibel/Telepathy move
> > - Make Kopete protocols available as Telepathy connection manager
> > I know that Will is going to look into making our protocols available as
> > connection manager.
> > Also the plan is to move most of code in Telepathy plugin into the core
> > and make use of Decibel (which currently Telepathy plugin doesn't use).
>
> Working on that now and at the hackathon this weekend.
>
> However, manpower and time are our greatest problems.
Damn time and lack of motivation ;)
> Will
--
Michaël Larouche
KDE developer working on Kopete, Gamefu(KDE), Solid...on dial-up :P
--------------------------------------
Website: http://www.tehbisnatch.org/
MSN: [EMAIL PROTECTED]
IRC: irc.freenode.org/DarkShock
Jabber/email: [EMAIL PROTECTED]
pgpCOnQPRZvXH.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
