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

List:       kroupware
Subject:    Re: [Kroupware] Kaplan: The road ahead
From:       Matthias Kalle Dalheimer <kalle () klaralvdalens-datakonsult ! se>
Date:       2002-09-19 5:23:39
[Download RAW message or body]

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

_______________________________________________
Kroupware mailing list
Kroupware@mail.kde.org
http://mail.kde.org/mailman/listinfo/kroupware
[prev in list] [next in list] [prev in thread] [next in thread]