[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 14:50:20
[Download RAW message or body]

On Saturday 27 December 2003 14:02, Tobias Koenig wrote:
> On Sat, Dec 27, 2003 at 01:25:47PM +0100, Cornelius Schumacher wrote:
>
> > 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.

You don't need a query language for that. There is only a limited set of 
queries which is used by most of the code. This can easily coded into 
some special search functions.

Another question is, if all data of an addressee has to be loaded, when 
the addressee itself is loaded. For file-based backends this probably 
isn't a question, because it is hard to implement, but for database 
backends it might be more efficient to only load the fields which are 
actually used. This could be done by an additional data handling object 
inside the Addressee class to actually access the data. This object 
could be provided by the Resource creating the Addressee.

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

Covering 80% is already quite good. In addition to that a generic query 
for a specified field would cover almost all other cases.

> And there may be many more applications which like to use this search
> feature.

Which applications would use multiple search expressions with complex 
matching conditions? That's the only case where a query language would 
really be beneficial. Free-form search is the only application I see 
for that and there we still have the problem that's almost impossible 
to provide a decent GUI for it.

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

The components would use libkabc to access the data. If libkabc accesses 
the data via a dcopservice doesn't matter. That's exactly what we 
already have now.

> The search query method would still be missing...

We can add one, if we have an application for it.

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

What use cases do you have in mind?

It might be useful to have a DCOP call to add certain resources, so you 
could easily import e.g. an external data source into the addressbook, 
but the problem with the generic resource handling you describe above 
is that a Resource is a complex class which isn't described by an uid 
alone, so you would need a way to access all the additional data. I'm 
not sure that it is really desirable to export that much internal 
information of the addressbook via DCOP.

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

Yes, that would be useful. Jan-Pascal already suggested a patch for 
libkcal to implement something like that a while ago (this reminds me 
that I still have a couple of patches to review on my todo list).

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