|Cornelius Schumacher||Oct 13, 2001 1:11 pm|
|Daniel Molkentin||Oct 13, 2001 1:54 pm|
|George Staikos||Oct 13, 2001 2:07 pm|
|Shawn Gordon||Oct 13, 2001 2:24 pm|
|Daniel Molkentin||Oct 13, 2001 2:30 pm|
|Alex Zepeda||Oct 13, 2001 2:41 pm|
|Shawn Gordon||Oct 13, 2001 3:10 pm|
|Ellis Whitehead||Oct 13, 2001 4:35 pm|
|Cornelius Schumacher||Oct 14, 2001 2:18 am|
|Cornelius Schumacher||Oct 14, 2001 2:41 am|
|Rik Hemsley||Oct 14, 2001 4:42 am|
|Cornelius Schumacher||Oct 14, 2001 6:22 am|
|Cornelius Schumacher||Oct 14, 2001 9:31 am|
|Rik Hemsley||Oct 14, 2001 10:49 am|
|Cornelius Schumacher||Oct 14, 2001 2:50 pm|
|Carsten Pfeiffer||Oct 14, 2001 3:10 pm|
|Don Sanders||Oct 15, 2001 8:02 pm|
|Cornelius Schumacher||Oct 16, 2001 1:31 am|
|Don Sanders||Oct 16, 2001 4:28 am|
|Cornelius Schumacher||Oct 16, 2001 7:09 am|
|Don Sanders||Oct 16, 2001 4:28 pm|
|Subject:||Re: Request for comments: New address book API|
|From:||Cornelius Schumacher (schu...@kde.org)|
|Date:||Oct 14, 2001 2:50:07 pm|
On Sunday 14 October 2001 19:49, Rik Hemsley wrote:
#if Cornelius Schumacher
Per-record locking could be done by splitting up the file and store one record per file, but this would also complicate the API. Is this really worth it? What are the advantages?
Well, just imagine if the entire CVS repository was locked when one person committed changes to one file, and they were doing this over a slow link...
Yes, but this is a different application. In CVS you have thousands of files and many different people are frequently accessing these for reading and writing. For the addressbook I would assume that the typical case is a few dozens entries and most of the time a single user is accessing them read-only. Even if you take into account shared address books on a server I don't think that it happens very often that two users are writing to the address book at the same time.
BTW, storing the entire db in one file is risky, no ? How do you write ? Write an entire new file, then mv ? If you don't, how do you cope with a server crash ?
Good point. File saving could be made safer, that's right, but at the moment this is just an implementation detail, we can work on things like that later.
Merging changes can be quite difficult, if different changes have been done to the same record. This might not be possible without user interaction and even then you need the locking for the time of the merge.
Yes, it would require user interaction, but if the user makes changes and tries to commit them, then you see the record has changed since you last looked at it, you have to merge anyway, so I fear this is unavoidable.
If you lock before you do any changes than you don't have to merge. It can for example happen that you are not allowed to edit a an address in KAddressbook for a short time because KPilot is syncing the address book at the same time, but you never have to merge different changes.
Since I assume that writing to the address book is not done very often, I think that locking is appropriate in this case. For things like syncing the complete address book with another address book (e.g. on a Palm) you need locking of the complete address book anyway. If we find that this is to restrictive in practice, we can add per-record locking later.
-- Cornelius Schumacher <schu...@kde.org>