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

List:       kde-pim
Subject:    Re: [Kde-pim] Minimum requirements to make a QT app into a KDE app?
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-11-06 16:34:14
[Download RAW message or body]

On Wednesday 31 October 2001 18:13, Bryan Brunton wrote:
> << Consider that your application is competing with KAddressbook and
> KOrganizer. Therefore some compatibility is essential. In particular there
> are applications that rely on the existence of the DCOP interfaces of
> KAddressbook and KOrganizer for their operation. Take them into account. >>
>
> I'd like to have as much compatibility as possible.  Who knows, potentially
> have the ability to add folder types that are KAddressbook or KOganizer. 
> That's kinda a distant dream at this point. The few sticking points are:
>
> (1) my application is cross platform.  Initially I am designing it to be
> portable to Windows/Mac. Additional KDE integration will have to come
> later.  Right now just aiming for the minimum. Eventually some import and
> export mechanism from the KDE apps would be nice.  Obviously some levels of
> KDE integration (such as DCOP) might not be possible.

Why do you want to reinvent the wheel to be portable? It's certainly less 
effort to make the kde-pim apps cross-platform than to write yet another 
addressbook and yet another calendar.

> (2) my application is a multiuser client/server application using QT3
> database support.  While KDEPIM suite shows great potential, the amount of
> code and hackery required for functionality that essentially re-implements
> old school database application functionality is significant and, IMO,
> kludgey.  Here on the client side I am talking about things like databound
> widgets in QT3.  Then on the backend side there are significant things like
> record locking and data integrity that I don't think the current KDEPIM
> suite can guarantee.  Obviously, the KDEPIM applications are single user so
> these robustness issues are not as significant, but the amount of code
> required to write a simple application like KAddressBook is alarming.
>
> But I'm very ignorant about the KDEPIM suite, most of my talk here is
> conjecture.  Perhaps the address book API allows the use of a real database
> server as a backend?  But then I would be concerned that using such an API
> inserts another point of failure, another code base that needs to be
> updated, a code base that could never evolve fast enough the applications
> it servers.

It's possible and planned to add a database backend for storage of 
addressbook and calendar information. The level of abstraction added by the 
APIs handling this data are useful, because they separate the GUI from the 
details of the storage of data. The database-aware widgets might be easy to 
use for small projects, but in the long term it will become a problem to tie 
the GUI to the storage layer. One example are daemon-like programs, which 
operate on your address book or calendar data, you have to rewrite everything 
to make such a program to not require a running X server. This is a nightmare 
to maintain. With the level of abstraction provided by the APIs of kde-pim 
this can be solved in a much more clean way.

I don't understand your concern of the additional point of failures. The 
right abstraction layers eliminate points of failures, because they reduce 
code duplication and dependencies.

> Essentially I am concerned that the KDEPIM suite can NEVER provide robust
> multi-user applications without putting in support for the use of a
> traditional database server on the back-end.  I think that potentially
> there is a danger of re-inventing the wheel in an entirely unsatisfactory
> manner (such as the horrible virtual file system solution that Aethera
> tried to use).

As said before, implementing database backends is not a big problem, and this 
should be done at some point.

But just having the database is far from being a complete solution. You also 
have to get the GUI right to handle multi-user access in a decent way, which 
is not easy, because you have to deal with things like authentication, 
externally changed data, rejected transactions, slow or failing network 
access etc.

In addition to that you have to solve the problem of interoperability. Using 
a custom database might be good for some small applications, but in real life 
you want to access the standard servers, like LDAP, Exchange etc. This is 
another reason why it is good to have an abstraction layer seperating the 
data access from the GUI.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]