On Wednesday 14 March 2007 17:54, Michaël Larouche wrote: > 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. >
Be prepared to abstract out the kDebug calls then.
> 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.
>
I'm not sure that this is correct. No decision has been made about SSL support
in kdelibs yet. I think we as Kopete developers would prefer to use QCA as
the backend, but the work for that would need to be done by somebody who
would be interested.
> 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.
>
From the OSCAR point of view, i'm not to interested in this. Why? Because
liboscar will eventually become standalone as soon as I can get it done since
I have at least one other IM client that has expressed interest in using it.
> 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
>
wrong and wrong. OSCAR uses kdelibs. Papillion, if it uses kDebug (and it may
not), uses kdelibs. Any other protocol that uses kDebug in the backend uses
kdelibs.
> > > 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.
>
And we need to be able to support those features. Anything that prevents us
from doing so is not a viable solution for our needs.
> > > 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.
> >
Then we can't call the Kopete that ships with KDE 4.0.0 version 1.0
> > > # 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 ;)
>
Bah. Speak for yourselves. I'm more productive than ever. :)
--
Matt
pgp3NWhH4QBaf.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
