[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:       Tobias Koenig <tokoe () kde ! org>
Date:       2003-12-27 13:02:34
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sat, Dec 27, 2003 at 01:25:47PM +0100, Cornelius Schumacher wrote:
> On Friday 26 December 2003 16:14, Tobias Koenig wrote:
Hi Cornelius,

> 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. 
It's not only interesting for free-form searches, but also for fast and
memory friendly data access. The single apps don't have to request 'all'
contacts (which results in duplicated memory consumption), but ask the
server to send them only the contacts they want to have.

> For contacts this would be lookup of names and email addresses, for 
That covers ca. 80% IMHO, but what's about the Kaller application, I
guess it would like a query like searchContacts( PhoneNumber,"223462534", Equals )
to get the contact of the current caller.
And there may be many more applications which like to use this search
feature.

> calendar data, time-based lookup.
ACK

> > 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?
It doesn't had to know, providing these components is not directly tied
to the dcopservice concept, but imagine we would provide components with
the current libkabc... every small app which uses them would have a copy
of the whole address book in memory!
Now with the central dcopservice the whole address book is in memory
only once and the single components have just a subset of contacts in
their memory space.


> 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.
Yes, it _might_ ... we should try to make it as fast as possible and
compare it then with the current model.

> > 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.
The search query method would still be missing... Furthermore I'd like
to change the resource handling in libkabc to make it more user
friendly.
There would be dcop calls
  addResource()
  editResource(uid)
  removeResource(uid)
  enableResource(uid, bool)
  QMap<QString name, QString uid> resources();

which allow _every_ dcopable application to manage the resources.

Furthermore we can introduce locking/unlocking of single contacts, not
only the whole resource.

Ciao,
Tobias
-- 
Can a government that shoots at reporters be democratic?
Separate politics from religion and economy!

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]