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

List:       kde-pim
Subject:    Re: Moving low-level calendaring code to own library
From:       "Aaron J. Seigo" <aseigo () mountlinux ! com>
Date:       2001-04-17 23:30:11
[Download RAW message or body]

Hi...

> What would have an addressbook and a calendar server in common? I don't
> think they would share much code. If the only reason would be to reduce
> the number of servers I don't think it is worth the hassle of tying
> together two separate applications.

it seems fairly obvious (to me at least) that address book and organizer 
information are often used in conjunction with each other. therefore having a 
single repository for this data would make using the data easier and more 
flexible. some of the advantages/applications i can think of off the top of 
my head:

- having an appointment pop up and being able to access the address book
   entries for all those involved. 
- being able to access an address book entry and pick up all the appointments 
   attached to that individual. 
- changing information in the address book could be reflected instantly in 
  all appointments that individual is included in. 
- elimination of redundancy between the address book and the calendar, such
   as storing a person's birthday in the address book, which ought to be the 
   organizer as well, IMO.
- when accessing the address book via apps that use it (such as kmail) the
   user could then also see the appointments, etc. associated w/address \
   entries

while much (if not all) of this would still be possible with 2 separate 
servers, it would not be nearly as elegant or likely to be implemented IMO... 
it also opens up the possibility of eventually merging in other bodies of 
data, such as knotes, to provide a rich and useful PIM system integrated into 
the desktop... 

extending this framework to share information with other desktops via the 
network could be another eventuality if all this information was available 
via a single point of contact.

-- 
Aaron Seigo

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