[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:       Bryan Brunton <bryanbrun () yahoo ! com>
Date:       2001-11-09 19:15:28
[Download RAW message or body]


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

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.

Or in the case of a small business like a law firm these people want a simple useable application
in which to enter their client (a superset of what you know as a contact) information and print
out documents.  The typical law firm has two to three PCs.  These people spend their entire work
days inside a couple applications that do everything for them.  Interfacing these applications to
the corporate level LDAP, Exhange, Notes server is meaningless to the people.

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.

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

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.


Bryan


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
_______________________________________________
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]