[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Re: [Kroupware] Kaplan: The road ahead
From:       Don Sanders <sanders () kde ! org>
Date:       2002-09-19 7:36:58
[Download RAW message or body]

I'm really happy to see kroupware team showing an interest in working 
with kaplan/kontact.

I see this act of treating us as friends when we could be seen as 
enemies as a very open minded, generous and commendable act.

I hope that I can be mature enough to respond in the same way.

Don.

On Thursday 19 September 2002 15:23, Matthias Kalle Dalheimer wrote:
> On Wednesday 18 September 2002 21.42, Daniel Molkentin wrote:
> > Moin!
> >
> > This is a status update on Kaplan development and a RFC at the
> > same time that many people have asked me fore to step forward in
> > Kaplan Development. I just wrote down some points and I am
> > curious about your opinions.
> >
> > 1) Kaplans general design
> >
> > At the moment Kaplan bases on an abstraction through plugins,
> > that get loaded on startup and hold some information about the
> > Part to be loaded. I would prefer if we could get rid of this
> > cruft. All information we need can be put in header files AFAICS.
> >
> > - Let KParts communicate directly
> >
> > I think this question is pretty much clear: If we can, we should
> > use kparts directly just like the kroupware guys do wherever
> > possible. I think the current design in the kroupware branch to
> > move the functionality into seperate classes might ease porting.
> >
> > 2) Kaplans name
> >
> > I agree with you that Kaplan is not a real good name for a
> > consumer product. I agreed with Don to call it Kontact. We will
> > switch the name at some point but I consider other (design)
> > decitions to have precedence.
> >
> > 3) Configuration of the Parts.
> >
> > Do we agree that Kaplans Parts should store their config stuff
> > into kaplanrc when loaded as parts? How could a merged
> > configuration look like? I think Don did some researches in that
> > area. Any news?
> >
> > 4) Kroupware integration
> >
> > Ok, let's see what they have so far and who is in charge:
> >
> > - Offline IMAP:
> > That's obviously a KMail thingy.
>
> Agree.
>
> > - Handling of incoming VCal Events and:
> > Cornelius should probably comment on that. Anyone?
>
> We had discussed this for a while in the Kroupware project. You
> don't want just another full-blown vCal parser in KMail, so we
> decided to have a five-line mini parser in KMail just for
> recognition, and then pass the vCal to KOrganizer for correct
> parsing and handling.
>
> > - The KOrganizer side:
> > Looks like we won't need to change too much, I am currently
> > trying to get kroupware_branch working to get an impression.
>
> Since we are using KParts here as well, that should be easy to
> integrate. Maybe you don't have to change anything at all; making
> KMail a KPart shouldn't have any influence on how KMail and
> KOrganizer talk to each other.
>
> Kalle
>
> > - KAddressbook: Any strong feelings on the integration of the
> > addressbook (other than showing it?)
> >
> > 5) Myself and my involvement.
> > I will again start to activlely develop on Kaplan. The Problem is
> > that university starts by the beginning of next month and I will
> > have to concentrate on that for the next time. I think we can
> > find an interim maintainer for that time. Just tell me if you
> > want to step in when the time comes...
> >
> > 6) Testing accounts for the Kollab Server:
> > Martin, I (and maybe others, too) need an account for the Kollab
> > server on alpha. Would that be possible?
> >
> > Ok, that's all for now (pretty short I know, but it's getting
> > late). I am curious for your oppinions and my inner hope is that
> > we can show first results of Kaplan + Kroupware at LinuxWorldExo,
> > but that's in no way a promise.
> >
> > Cheers,
> > 	Daniel

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]