[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-10-31 17:59:04
[Download RAW message or body]

On Wednesday 31 October 2001 12:13 pm, 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. >>
> <snip>

i just started using korganizer yesterday, and i'm pretty happy with it, but 
there are some things that i'd like that just aren't there so i went to look 
at virtualaw. i like your ideas, and you're going the right direction for 
stuff i was thinking about yesterday. the only differenct is the eventual 
endpoint that an application like that could be used for (two different needs 
with a common backbone. hmmm... :)

i'm looking for something that has the capability to
	a) manage contacts on a personal and system wide level
	b) provide comprehensive task management
	c) provide time management capabilities for billing statements
		- i worked 10 hours on project A yesterday and
		  3 hours on project C.
		- note that these aren't really the same as events
	d) integration with a system wide project management tool
	e) integration with project development tools (documentation,
	   software design, coding).

pretty useful stuff for a software engineer. anyway, alot of the core is the 
same and the rest could just be "plugged in" to provide integration to 
various application spaces.

if you'd be interested, here are some thoughts (essentially, the 
specification part of the software design process):

> (1) my application is cross platform.  Initially I am designing it to be
>
> (2) my application is a multiuser client/server application using QT3
> <snip>

i'm down with client/server topologies - hell, that's what i do for a living 
- but it sounds to me like you're missing a layer. typically, a *good* system 
for doing things like you're talking about comes in 3 tiers:
	- data services (the data base backed and DB tables)
	- presentation services (middleware)
	- application services (gui's, web access, etc.).

consider the pim application space. what would you need to know about a 
contact?
	- name (first, last, middle, title?)
	- address (home, work, alternate)
	- phone number (home, work, cell, additional numbers)
	- fax number (home, work, etc.)
	- email (personal, work, others)
	- notes
	- other (web page, etc.)
essentially, what you have is an extensible set of fields and values. really, 
you could define a contact to be a 1-n relationship between a unique 
identifier (primary key) and a bunch of fields. each field could contain some 
essential type definition that tells the presentation layer how to present 
the data. for example, you could define a birthday field where the type would 
be a date - or a "last seen" field where the type would be a date and time 
value.

now consider technologies that you could use to store that information:
	- flat file for local only access
	- data base (relational, OO)
	- LDAP/X.500
	- XML storage (not really a backend, but something to consider)
do you want to support all of those backends? if you do, the presentation 
layer must be capable of communicating with all of them regardless of the 
specific back end implementation. that makes things pretty tough. targetting 
one isn't so bad :) for example, ODBC drivers can be used to make all data 
base access look the same.

then, you need to think about how people would want to view that information. 
typically, for PIM type stuff, there's a system-wide component that accesses 
your personal contacts (KAddressBook). alternatively, you could use a web 
browser to see your contacts.

the web services part is where things actually get interesting because it 
provides a very common and available mechanism for accessing information 
across an enterprise. consider M$ project. that has a tie in to IIS that 
allows users to simply browse to some web page and see the project, check 
tasks, change statuses, view the gantt chart schedule, etc.

of course, there are many, many other requirements that need to be 
considered. things like security: who can update personal information? who 
can access personal information? is it possible to subgroup your contacts? 
stuff like that.

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

i would agree with you here. there should be some fantastic application out 
there that allows plugins to extend the capabilities of a simple PIM core to 
include things like system wide management, real project management and tie 
ins to the actual project. by the way, if you ever get to that point - take 
software design for example - you go to see the project, somebody has 
assigned you a task to fix a bug in a file, so you simply open that file 
directly thru the project management tool, make your changes and its 
automatically checked in and updated when your done - then you'll be a couple 
of steps ahead of M$.

if you're interested in having another developer for that stuff, my time is 
kind of scarce these days, but i'd be interested in helping out when and 
where i can.

Andrew Sutton
ansutton@sep.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]