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

List:       kde-pim
Subject:    Re: [Kde-pim] Proposal: KSharedFile
From:       Ingo Assenmacher <mlists () cognitivemicrosystems ! net>
Date:       2001-12-08 16:26:46
[Download RAW message or body]

Hi.

Am Samstag, 8. Dezember 2001 01:02 schrieb Cornelius Schumacher:
> On Friday 07 December 2001 19:52, Ingo Assenmacher wrote:
> > But why do not use a database with transactions and
> > multiuser-evironment to solve concurrency issues here. Instead of
> > KsharedFile make something like KFileProxy and connect to a database.
> > Concurrent access to data including integrity issues have been solved
> > for many years now by database systems. So why keep up with fragile
> > file-based manipulations and lock-files?
>
> but on the other hand it would
> create a lot of other problems, for example more difficult debugging.

I do not agree.  Using modern API-interfaces for dbases uses the whole 
complex as a black box. Debugging actually becomes easier.
At least that is the experience after my last projects working with dbases.

> The kdepim tools are still aiming at the "normal" user, where using a
> real database as backend would really be overkill.

I do not think that this is true. 

a) Why do you think a "normal" user, running Linux/KDE is not capable of 
installing e.g. postgres? Using its rpm, installation in trivial. Except for 
some security issues which are fairly good documented, there is no need for 
manual interaction besides the installation. (In addition: there are nice 
KDE-based clients and administration tools for the most popular dbases 
already existing).
b) I mentioned the concept of a proxy object which could handle dbase 
interaction, the normal user would not even see that the dbase is contacted. 
This would include user and schema creation/maintenance.
c) I do not the the argument for the "overkill". It is data we want to store, 
retrieve, manipulate concurrently (maybe from different users on different 
machines). These are the reasons for dbase development.

However, I do see that connecting a feature to a product which is maintained 
by other projects might be a drawback. For that reason I would emphasize a 
Proxy-Object and have loose coupling (which does minimize, but not eliminate 
problems arising here).

> That said, I still think that adding an (optional) database backend to
> apps like Korganizer and Kaddressbook would be a nice thing, but not a
> number one priority.

I agree. There are more important things to do. All I am trying to say is 
that implementations of problems that have been solved are unessecary, as the 
usage of existing tools/APIs is not complicated and stable. Implementing a 
Data-Entity object like KSharedFile (e.g. KDBData) with roughly the same 
interface, extracting data using the dbase API would be a lot faster than 
trying to experiment on the numerous pitfalls in 
user-synchronization/management, concurrent updates and data-storage.
I am busy up to the end of this year but I am volunteering to help here, if 
there is interest (in  the next year, lets say Jan/Feb).

> l also don't think that file-based manipulations and lock-files are
> fragile. They work very well and provide all the functionality we need.

Ok, that was not my real point.  See above.

Regards, Ingo.


_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim

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