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

List:       kde-pim
Subject:    Re: [Kde-pim] Kaplan: The road ahead
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-09-18 22:30:16
[Download RAW message or body]

On Wednesday 18 September 2002 21:42, Daniel Molkentin wrote:
>
> 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.

I think the main point about Kaplan is that it achieves integration of 
PIM/Groupware apps without creating dependencies on each other in the 
application code and without sacrifying the ability to run them 
stand-alone.

The plugin concept was inspired by the gideon. There might be better 
solutions, e.g. a special KPimPart derived form KPart providing the 
necessary infrastructure for communication between parts. But this 
doesn't matter much. As long as the tasks of integration is kept in the 
Kaplan framework and the task of providing the functionality is left to 
the application code we are on the safe side. Changing either of them 
will affect the other components.

Another important concept is that most communication is done via DCOP. 
This allows for both, interprocess communication between stand-alone 
apps and efficient in-process communication between KPart based 
components.

By doing the integration with plugins/Kparts and DCOP we minimise 
compile time dependencies, make use of the existent mechanisms to 
resolve run-time dependencies and cleanly separate the integration code 
from the actual functionality. This is a good thing and I'm happy to 
see that almost all of us agree on that.

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

I don't think that this is of any importance right now. Both names are 
fine, but currently we should concentrate on the code I think.

> 4) Kroupware integration
>
> - Handling of incoming VCal Events and:
> Cornelius should probably comment on that. Anyone?

I still think that a plugin interface for filtering mime objects in 
KMail would be the right way to pass iMIP requests to KOrganizer. You 
register a plugin for the mime type text/calendar and when KMail sees a 
mail containing an object of this type it decodes it and passes the 
information to the plugin by native C++ calls. The plugin 
implementation (which could be anything from a simple program just 
passing the data to the iMIP incoming directory of KOrganizer to a full 
KOrganizer providing dialogs and preview) does the further processing. 

Sending events from Korganizer to KMail via DCOP is fine with any way of 
integrating the programs.

And once again: It's not vCal events, it's iMIP, which is an 
implementation of iTIP using email as transport layer based on the 
iCalendar format. vCalendar is an old format which isn't used for group 
scheduling. There already have been confusions about the kroupware 
project using obsolete technology because of this, so please get the 
terms right.

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

KOrganizer has to provide all its actions in the KPart used by Kaplan. 
At the moment it only provides the actions needed for a read-only part. 
Kroupware creates the missing actions in the KMail code. This should be 
changed to be reuse the code within KOrganizer by making it a bit more 
modular.

> - KAddressbook: Any strong feelings on the integration of the
> addressbook (other than showing it?)

Most integration work is alread done by using libkabc as common library. 
In adition to that we have drag&drop and some DCOP calls. In my opinion 
KAddressbook proves that the Kaplan concept really works. With almost 
no work we got it intgerated with the other apps in a way very similar 
to Outlook and its clones.

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

I'm tired of maintainer discussions. I vote for collective ownership of 
code. We have a common goal and if all involved people do their 
contributions in a responsible way there shouldn't be any problem.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]