[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 10:10:16
[Download RAW message or body]

On Wednesday 30 October 2002 16:25, Holger Freyther wrote:
> Besides that I believe a Kaddressbook Resource needs
> more than load and write functions. 

I absolutely agree.

> We at Opie came to the
> conclusion that many resources have features which would get
> crippled or reimplemented for some resources. If you use a database
> it's first enough to load all UIDs and only the record behind the
> UID if needed.
>
> SQL databases give you indexing and queries in quite
> a confortable way.
> Opie common backends mostly have more than load and write
> functions. They've methods for sorting(), queryByExample(), add,
> remove,delete this way we can assure that the resource can do it's
> best. So if you use XML as a storage you can keep a journal in the
> backend. If you use a SQL backend you can quite easy to
> queryByExample and sorted stuff which needs some extra stuff to get
> the items. sorted..
>
> The OPIE PIM	LIB(which is wip)  can be found here :
> http://cvs.handhelds.org/cgi-bin/viewcvs.cgi/opie/libopie/pim/
>
> It's using templates, special iterators which actually only keep
> the uid and on dereferncing it's 'finding' the Record behind the
> uid. The we've a QCache there...

I think I know where you are coming from.

But ideally you don't even have to load all the UIDs. All you need is 
the number of entries and the ability to retrieve entry i when 
sorting by field x. This way you don't have to retrieve any 
information about an item until it is painted (which I think is 
ideal)

This is very much the case that QTable is optimized for (see large 
tables in the QTable documentation), but also (with work) QListView 
can be made pretty fast also.

Basically libkabc should provide an interface so that a QTable can be 
used to efficiently show address book entries.

I think this will also be useful to handle massive shared information 
bases that are continually updated. For instance consider an address 
book containing a million entries that is shared between a million 
users who want to see each others changes in real time.

Let's also assume there's a database that can handle that kind of 
load, and that the address book is being updated tens of times per 
second.

Then a KAddressBook view based on a QTable can just update n times per 
second, checking to see if the number of address book entries has 
changed (and update the number of rows accordingly), and check the 
range of rows shown to see if the corresponding address book entries 
are out of sync and if so update the appropriate QTable cells.

Basically if the library interface is done right even for very large 
information bases being updated continually in real time the viewing 
application only has to do a small amount of work to keep in sync.

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]