[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:       Andrew Sutton <ansutton () sep ! com>
Date:       2001-11-01 5:21:34
[Download RAW message or body]

On Wednesday 31 October 2001 04:04 pm, Bryan Brunton wrote:
> I really need to come up with a name for the Contact/Task/Calendar
> management application to differentiate it from VirtuaLaw.  VirtuaLaw, as a
> legal case management system, will use the contact/task/calendar
> functionality.  It will add additional functionality for managing cases,
> doing legal billing, etc.  They will however be entirely different
> applications.

the real topic you're dealing with here is generally called informatics. for 
example, all the digital information that floats around attached to a patient 
(demographics, healthcare info, etc.) is called healthcare informatics - a 
vast extension and specialization of what we're dealing with.

i like the name KInformatics for the base architecture :)

> The contact/task/calendar application can be viewed as a backbone on which
> other applications could be built.  IMO, the level of integration required
> goes way beyond the "plug-in" methodology that has been espoused by KDEPIM
> people here.  I can't agree that you can build meaningful integration on
> top of a contact/task/calendar application using plug-ins.  By meaningful I
> mean far reaching application functionality that changes or adds to the
> idea of what a contact or task is, and how they interact with additional
> functional components.  Doing plug-in integration like this and maintaining
> a useable UI is real hard.

you're right. this above and beyond the plugin system. this is an excercise 
in integration and extension. not very easy to do. i would suggest just 
tackling one small thing at a time. informatics can be broken into various 
segments. one of the easiest to consider is the contact information segment. 
it encapsulates all the information you'd want to know about a single person.

> What you describe here is the ideal.  I simple don't the have time and or
> inclination to design the ideal multi-tiered application.  I am also
> attempting to make this as simple a design as possible.  I am using QT3
> databound widgets.  These talk directly to database drivers so a truly
> separated middle layer isn't possible.  I have, however, separated most of
> the business logic into classes that will allow the use of different
> databases (anything that QT supports) on the back end and provide for
> separation between presentation and domain.

actually, the design shouldn't be that complicated. encapsulating the 
business logic in a single object is a good start. i'd just take that a step 
further and develop a "driver" specifically designed to load information from 
that segment. for example, contact information drivers could be used to lift 
contacts from a relational database, LDAP, outlook files, KAdressBook, etc. 
the driver would provide a base interface for creating, deleting and 
modifying contact information records.

a second driver could be used to manage lists of those groups. hell, an 
application could allow a user to simultaneously use several different 
address books (like a company wide LDAP server AND their local KAddressBook).

> Anyone who wants to help is welcome.  I should acknowledge that the goal,
> at least for the initial release, is to make as simple and functional a
> multi-user contact/task/calendar management tool as possible.  I won't be
> entering into an Aethera-like quaqmire.  I am not designing the next
> generation of contact management application servers.  With that
> acknowledged, I think that given the ease with which I progressed so far, I
> can have a functional, multi-user contact/task/calendar management system
> released in a few months time.  Possibly three to four months after that I
> can have basic email integrated into the system.  People will have a choice
> other than Evolution for an integrated open source system like this on
> Linux.


> I have considered doing a PHP based interface to this system as I have lots
> of PHP experience.



> I have considered doing a PHP based interface to this system as I have lots
> of PHP experience.
_______________________________________________
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]