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

List:       kde-pim
Subject:    Re: [Kde-pim] the goal of kaplan
From:       Don Sanders <sanders () kde ! org>
Date:       2002-10-31 8:52:19
[Download RAW message or body]

On Thursday 31 October 2002 02:23, Anders Lund wrote:
> On Wednesday 30 October 2002 06:54, Don Sanders wrote:
>
> Hi Don,
> Glad to hear from you in this respect :)
>
> > On Thursday 17 October 2002 08:22, Anders Lund wrote:
> > > On Wednesday 16 October 2002 13:15, Tobias Koenig wrote:
> > > > On Tue, Oct 15, 2002 at 10:41:18AM +0200, Anders Lund wrote:
>
> ...
>
> > > This discussion involves KOrganizer, KNotes and more apart from
> > > the addressbook, and they are all using field data.
> >
> > KMail too.
>
> Sure!
>
> > > Consequently a
> > > fields feature should be shared by them, along with other
> > > common objects, a common folder mechanism for example. Apart
> > > from adding to the commonality of the existing specialized
> > > apps, kaplan would greatly benefit from common objects, for
> > > example user defined data collections/forms would be easy to
> > > implement and of cause also benefit from the existing
> > > interfaces.
> >
> > In the long term I agree that more commonality has promise.
>
> Given the work beeing done with kaplan and kgroupware, I think
> now:-)

I agree there is a lot of opportunity to generalize concepts:

http://lists.kde.org/?l=kmail&m=103252356610599&w=2

But at least from my perspective the timing is right, I'm not able to 
focus on this now or even in the short and medium term.

> ...
>
> > Whether or not a database is used is just an implementation
> > detail, what's more important is to consider the address book
> > library interface.
> >
> > Ideally I would like to be able to index the addressbook on
> > arbitrary fields (namely those fields shown in the default
> > addressbook view).
> >
> > Then the address book interface should support querying the
> > number of address book entries, and retrieving a range of
> > entries. So I can say give me entries 10-30 when sorting by date,
> > and perhaps give me entries from 2001-10-30 to 2002-10-30 when
> > sorting by date.
> >
> > This is needed for scalability.
>
> I completely agree. With indexes, a lot of things would be solved.

Cool.

> > > If we want efficiency - speed as well as system resources - for
> > > example a view that displays only names and phonenumbers would
> > > load faster and use significantly less system resources using a
> > > database. In the case of filtering this is even more true. And
> > > given a database interface,
> >
> > Again I think whether or not a database is used is an
> > implementation issue. Instead I think the important issue is
> > getting the methods I mention above into the interface.
>
> Sure. But the execution of some methods/queries should be left to
> the backend, is what I mean.

Okay.

> > > things like categories with no members
> > > or unused custom fields would not be fake like they are now
> > > (which would also yeld efficiency).
> >
> > I consider this a separate issue. Unfortunately I don't have much
> > time to discuss it, but I do think a database is just an
> > implementation tool for solving this problem, I think it's
> > important to look more deeply and say what are the essential
> > features of databases that are useful for solving this problem.
> > In this case it might be as simple as providing an interface for
> > retrieving and updating a list of categories and custom fields.
> >
> > > And for good usage of single datas, the good usage is related
> > > to knowing the type and beeing able to trust the integrity of
> > > the data source is as important as speed and system resource
> > > management. Meaning, if I want a field holding an integer, if
> > > the addressbook (KABC::AddressBook) can return an integer after
> > > checking the type, it yelds nice usability, otherwise it does
> > > not.
> >
> > I don't feel comfortable addressing this issue of types, I
> > suspect I lack sufficient domain knowledge to be able to comment
> > intelligently.
>
> To me, this is one of the most important issues to get on with
> extending the usability of the pim applications. So even I am not
> an expert in the domain either, I debate it, and tries to figure
> out what would be a good solution. The point beeing that we should
> not rush to use wrong or bad impelemtations, but we have to get
> started, and in my experience defining the needs and possible
> solutions is a good start: we are on the way...

(Again I can't currently add anything meaningful here).

> > > So if we want to promote KAddressBook for usage in new client
> > > applications, and implement some kind of custom data objects,
> > > forms etc, we need to provide the required tools for it. For
> > > libkabc, that means adding features for now, if we don't want
> > > to bite the apple and rethink it.
> > >
> > > I think that nothing would prevent the KABC::Field object from
> > > deriving a KDEPim::Field class that could provide the data type
> > > and convertions data<->string functionality required, and that
> > > such an interface would be easily adjustable to different types
> > > of data sources, including moving convertion back to the
> > > datasource level.
> >
> > Again this particular issue of types is not something I wish to
> > comment on.
> >
> > But regarding biting the apple now, I definitely would like to
> > address the issue of scalability sooner rather than later,
> > unfortunately I just haven't been able to find the time to do so
> > in the last year of so.
>
> Well, maybe we can find a way to get it done between the many
> capable developers involved:)
>
> > Let me copy and paste something from an earlier mail and reply to
> > it
>
> ...
>
> > There's no reason why storing address book entries in individual
> > text files can't be massively scalable. This is equivalent to
> > KMail handling mail in Maildir format, something it can do fine
> > for many tens of thousands of mails.
> >
> > What KMail does is store index information in .*.index* cache
> > files. You could use a database for indexing instead (there's
> > good arguments for and against) but that's an implementation
> > detail. The important thing is to get the methods required for
> > scalability into the inferface and those are roughly
> >
> > void setIndex( Field, bool ); // turns on/off indexing of a field
> > int entries(); // number of entries
> > FieldList values( Field, int start, int end); // retrieve values
> > from // start to end
>
> That sounds all correct. And indexing could be used to up the
> efficiency of the single vcf file format as well.

By single vcf file format do you mean all vcards in a single file 
rather (like mbox) rather than in separate files (like maildir)?

If so I agree.

Anyway I hope to return to this issue when I have time to discuss 
implementation details, but that time is not yet.

Don.

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