[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-09 22:13:49
[Download RAW message or body]

On Friday 09 November 2001 20:15, Bryan Brunton wrote:
> << I already mentioned the key problems like authentification and
> interoperability. These has to be solved, rewriting addressbook or
> calendar apps will not help very much. >>
>
> Authentication is no problem for my application because I am building
> my entire world.  Its a simple traditional client/server database
> application.  My authentication is either application level,
> username/password pairs stored in a db table.  Or in cases where the
> database supports authetication, I can use its authetication and
> security system.

But you still have to provide the GUI for this and handle passwords nd 
similar stuff, which raises security issues.

> Quite frankly, while interoperability is important for some users, I
> think that it is relatively meaningless for the majority of users. 
> By majority I am talking about the average single user installation
> or the small business case.  These people couldn't care less about
> interopting with LDAP, Exchange, etc.  Mention LDAP to the average
> home user and you will get a big blank stare. These people want a
> simple useable application in which to store their
> contacts/calendar/mail.

Tell these users that they have to install and run a complete database 
system for using your application and you will get a similar stare.

> Ok, now for the technical problems inherent in integrating an
> interopable contact system with these people's data and reporting
> needs.  Quite frankly I don't know how this could be done. These law
> firm people have client records.  Clients can be contacts.  A client
> is a contact with a large number of additional data fields. 
> Additional data tables that store things like invoices are associated
> with clients.  I really fail to see how this data entity known as a
> client is associated in an elegant way (and used programmatically)
> with a contact record that is stored in KAddressBook or a remote LDAP
> server.

If you use data in your client records, which is stored in KAddressBook 
(e.g. email addresses) or Korganizer (e.g. appointments), don't 
duplicate the data, but store a reference in your record (each 
addressbook or calendar entry has an unique id, whch can be used for 
such purposes). When you need this information in your application, 
read the reference form the database and ask the appropriate KDE APIs 
for the data. This might seem like an overhead, but in the end it will 
save you work, because you don't have to duplicate data and 
functionality.

> << You are right that it's easy to rewrite KAddressbook with less
> code in no time, but what do you gain? The problem is much deeper,
> e.g. the missing LDAP access or that KDE apps don't use the
> addressbook data in a consistent way. >>
>
> What I gain is the use of data entities (contacts, clients) that can
> be easily used and associated with other data entities (like billing
> records) so that I can easily and quickly write useful application
> functionality (printing out an invoice).  Interopability takes a back
> seat to USEFUL software.

I would consider a software that shares its email addresses with all 
other applications on the desktop as more useful than one, which 
maintains its own data.

The data entities used in kdepim can as easily be used and associated 
as any data in your database. If that's not the case, we should improve 
the relevant APIs until it's as easy as required. 

> Linux can't be used in law firms that want to use case management
> software, unless you run an existing Windows case management system
> using WINE.  The goal here is to provide people with choice.

Choice is good and I really appreciate your goal to provide a case 
management system. What I'm trying to say is that the stuff we have in 
kdepim should be good enough to serve as a base or at least as a useful 
addition for such a system. It should make the development easier for 
you, because you don't have to reimplement the basic stuff like mailer, 
address book and calendar and can concentrate on your actual 
application.

-- 
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]