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

List:       kde-pim
Subject:    Re: [Kde-pim] Writing plugin for kabc
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2004-03-20 16:59:33
Message-ID: 200403201759.33713.schumacher () kde ! org
[Download RAW message or body]

On Saturday 20 March 2004 17:36, Tobias Koenig wrote:
> On Sat, Mar 20, 2004 at 11:13:53AM +0100, Cornelius Schumacher wrote:
> > On Saturday 20 March 2004 10:14, Tobias Koenig wrote:
>
> > > 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_...

It will quickly become a language when you seriously want to move all 
the searching to the server. If not, then the existing query functions 
are almost enough.

> > > , 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)

But that's wrong. When you search for e.g. a date you don't want to pass 
a string as pattern. That's exactly what the libkabc API tries to avoid 
(for very good reasons).

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

Ok, I'm looking forward to this.

> > > 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?!?

What I wanted to say is that people already ask for this for a long 
time. This is nothing new.

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

Sure, but don't forget that it's still only a subset of users who need 
support for large addressbooks. 

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

Yes, that's a problem we have to solve. But that's exactly why we have 
to separate the browsing (iteration) case and the search case (which 
needs server access). Data you have locally available you can easily 
iterate over.

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

Sure, but how much searching can be done on the server differs, so you 
need the client side iteration and filtering anyway. If you allow for 
very general searches, this quickly will become a nightmare to 
implement.

> With a search API the filtering can be done on server side, so only
> the needed data are transfered.

Assuming the server supports the searching in the way you provide it in 
the API. This will generally not be the case.

> > 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 ;)

Not really. The access to the Fields is limited in a way which makes it 
at least very hard to abuse them for type-unsafe access.

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

You iterate over the locally available entries, nothing else. Which data 
you get from the server has to be specified in another way. Iterating 
over all the data of a server doesn't make sense. The search API should 
provide a way to specify how to access the data on the server and what 
to get to the client. The iteration has to be orthogonal to this. Then 
you will get both, the option to iterate your entries for the wide 
variety of client-side iterations and in addition an efficient way to 
access large data sets on a 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?!?

See above.

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

We have picture-book like modes in KAddressBook and that's how most 
people see their personal addressbook. Abandoning that would be stupid. 
If KAddressBook isn't able anymore to show a simple list of local 
address book entries in a list view without starting a search. people 
won't use it anymore.

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