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

List:       kde-pim
Subject:    Re: [Kde-pim] Proposal: KSharedFile
From:       Nick Papadonis <npapadon () yahoo ! com>
Date:       2001-12-11 7:29:28
[Download RAW message or body]


Am Samstag, 8. Dezember 2001 01:02 schrieb Cornelius Schumacher:
> > for many years now by database systems. So why keep up with fragile
> > file-based manipulations and lock-files?
> 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.

<nick>
Agreed.
</nick>

> The kdepim tools are still aiming at the "normal" user, where using a
> real database as backend would really be overkill.
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 

<nick>
It comes installed in many distributions.
</nick>

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.

<nick>
Are you experienced with database access?  Could you come up with a
schema if everyone interacted with you?  A minimally tested API we could
use?  This would really help progress.
</nick>

> 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).

<nick>
I strongly believe every piece of a users PIM data should be put in
one database.  Notes, Calendar, Todos, Contacts.  

- One location
- Other programs have easy access

It sound like you have some good ideas on design here.  Can you
elaborate on your plans with the database and proxy?  (I might have
missed them.)

If we can get a solid roadmap/plan in place, I will to be joining you in
Jan/Feb!

</nick>
_______________________________________________
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]