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

List:       kde-pim
Subject:    Re: [Kde-pim] Writing plugin for kabc
From:       Tobias Koenig <tokoe () kde ! org>
Date:       2004-03-20 16:36:50
Message-ID: 20040320163650.GB9920 () ghostdog
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sat, Mar 20, 2004 at 11:13:53AM +0100, Cornelius Schumacher wrote:
> On Saturday 20 March 2004 10:14, Tobias Koenig wrote:
Hi Cornelius,

> > > For large sets of data, especially if they are located on a
> > > potentially slow server load-on-demand is essential. We won't get
> > > away without that.
> >
> > A search _is_ a load-on-demand, just the contacts are loaded which
> > match the search criterion.
> 
> Sure. That's exactly what I'm saying. You will have the complexity of a 
> load-on-demand algorithm in any case.
Yes, but's easier to implement in a search API than in a iterator API ;)

> > Come one... we've discussed it now several times
> 
> Yes, and you still ignore the arguments against this. In all these 
> discussions you were the only one arguing in favor of your query 
> language.
At least Marc was IIRC, and this is no _language_...

> > , my query _language_ 
> > consists of search method with 3 parameters:
> >   - field descriptor (name, email, phone number)
> >   - the search pattern
> >   - the match type (starts with, ends withs, contains)
> 
> Are you aware of how many combinations this gives and the degree of 
> complexity especially if you consider that fields have different types? 
Pattern is always a string, that's exactly the same we use for
KABC::Fields... just a bit extended (not only one email or postal
address)

> How many of these are actually used in our applications?
You'll get your statistic after the CeBit, ok? ;)

> > With the current API we can't handle large data sets, but here at the
> > CeBit many people ask about handling >3000 contacts with KAddressBook
> > in their companies, so we already know what kabc should be able to do
> > for KDE 4.0.
> 
> Well, people don't ask for this since this CeBit, these requests are 
> much older. I agree that it would be nice to address this in a clean 
> way in a later KDE version.
Don't ask for this before?!? There where mails on the official kde
mailinglists, and also some private mails which addressed this issue
also before CeBit. It's just that now, where many company are faced
with a change to Linux/KDE, realize that they need an address book which
can handle a large number of contacts, so they ask it here at the
fair.

> > Yes, but only over a subset and you don't have to do all the
> >   if ( (*it).name() == xxx )
> >     do_foo_bar();
> 
> If it is a subset of the data or not doesn't matter for the code doing 
> the iteration.
It's not only about the iteration, it's mostly about the data that has to
be transfered from the server to the client.
With the Iteration concept, the filtering is done on client side, that
means all data have to be transfered to client (with a 30000 LDAP
directory that definitely sucks).
With a search API the filtering can be done on server side, so only the
needed data are transfered.

> In the iterator model you write it 
> down in plain C++ using the existing type-safe API.
With KABC::Field we've already semi-broken this concept ;)

> > Why should it be something different? Both are a collection of
> > contacts with special fields and you can handle both with the same
> > API...
> 
> You can handle them in the same API, but as you see in the current 
> libkabc you can't handle them in the same way.
Yes of course you can't, because we _have to provide an iteration API and
this requires all data from the server!!!

> The fundamental difference between the two kinds of collections
> is that you browse one and search the other.
> The API has to take provisions for this difference.
Why do we need this difference at all?!?
The user inserts contacts, the user searches for contacts, an address book
is not a picture-book, it's a database which stores information for the
user.

Ciao,
Tobias
-- 
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]