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

List:       kde-pim
Subject:    Re: [Kde-pim] Why does Korganizer not like December 22?
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-12-27 12:25:47
[Download RAW message or body]

On Friday 26 December 2003 16:14, Tobias Koenig wrote:
>
> We would have a central contact dcopservice which does the whole
> locking in an upper layer (no lock file is needed since the server
> knows which app uses which contact/resource) and has a simple query
> language for searching contacts.

Well, having a central dcopservice doesn't make locking any simpler. The 
service has to provide all the locking capabilities to the applications 
using the service which are now provided by libkabc or libkcal. In 
addition to that it has to do locking on the database/file level or 
whatever it uses, since a dcopservice is only available to a single 
user on a single X display. NFS-mounted homes, remote login etc has to 
be handled in some way.

A query language might be nice for free-form searches. For most other 
applications it's quite well defined how the data has to be accessed. 
For contacts this would be lookup of names and email addresses, for 
calendar data, time-based lookup.

> For all standard tasks (editing a contact, searching a couple of
> contacts, contact preview) so called components will be provided,
> which handle the communication with the dcopservice and shall be easy
> to integrate in other applications.

Could you elaborate a bit? Why would editing or previewing a contact 
need to know about how the data is accessed?

> I guess something similar would be possible for libkcal as well.
> With a query language there wouldn't be a need for loading the whole
> calender at once in every app. Instead KOrganizer could ask the dcop
> service for all events which exists for the current week, the current
> day or the next three days.

Yes, that's what the current libkcal API already provides. My main 
concern here is that this is something where peformance matters because 
it's used heavily by the GUI. If it needs parsing of a query in a query 
language plus all the DCOP overhead to get the data it might get to 
slow compared to the direct C++ object access we have now.

> IMHO we should pay more attention to this service/component based
> approach since it makes integration a lot easier (and via a dcop/dbus
> bridge even non-kde apps could use the data)

I don't get how it would make things easier. The key is to have a 
well-defined API. Implementation details like how data is actually 
accessed should be hidden by that API. It would be perfectly possible 
to add a dcopservice-based backend to the existing addressbook and 
calendar libraries without changing the API.

Interaction with other apps should be done by using this API. We could 
for example provide a addressbook data source for OpenOffice by 
providing an OpenOffice module which internally uses libkabc. In my 
opinion something like this is much more important than fine-tuning the 
backend implementation.

If we use a central service for providing the data or the current 
concept of multiple objects working on the same data in the file system 
or whatever the data is, is a matter of optimization. We are trading 
memory consumption (which is better, when the data is only hold once in 
memory as in the dcopservice approach) for access speed (which is 
better, when the data is directly accessed in memory as in the current 
approach). Where the optimum is isn't obvious at all, so if we really 
spend time on something like that, it will be crucial to make a decent 
analysis of performance and memory consumption, to carefully think 
about different areas of optimization and to look at other 
implementation of this kind of stuff (e.g. in Evolution). It wouldn't 
be the first design which looks nice on a first technical sight, but 
doesn't really work out in practice. 

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://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]