From kde-core-devel Sun Oct 14 21:50:29 2001 From: Cornelius Schumacher Date: Sun, 14 Oct 2001 21:50:29 +0000 To: kde-core-devel Subject: Re: Request for comments: New address book API X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100309659000436 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