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

List:       kde-devel
Subject:    Re: PeopleSpace <--> Kab Merge? (fwd)
From:       Mike Pilone <mpilone () slac ! com>
Date:       1999-01-22 5:34:01
[Download RAW message or body]

Hello all,

The past couple hours Preston Brown, Dan Pilone, and myself have been
discussing the idea of merging Kab and PeopleSpace. After long discussion
and many emails Dan came up with the following ideas, all agreed apon by
Preston and myself. Mirko is currently out of town so we haven't heard
from him. 

Please read over the following and let us know your opinion on the matter.
As of now developement of PeopleSpace is on hold until a decision is made.
Make all replies to the kde-devel list so everyone can see your opinions. 

If you don't know about PeopleSpace, checkout
www.slac.com/mpilone/peoplespace_home/

If you don't know about Kab, checkout
www.kde.org/applications

Dan's reply to the situation:
-- 8< -------------------------

	Hey.. great work on peoplespace.  I really like it.  I didn't
pound on it too much, but it seemed pretty sweet.  I added an account, 
used the list view, etc.. Anyway, here's my opinion (and you're free
to quote any of this to the kde-devel mailing list if you want to.)
First, peoplespace and Kab server different purposes, Kab is an
address book, simple and straightforward.  peoplespace is an address
book on steroid, well, better put, it's a contact manager.  They have
differen't purposes, and different audiences.  That being said, there
is a lot of overlap.  I think both can (and should!) exist, however,
there's a good bit of work to be done.  If Kab is going to be
rewritten, then it should be rewritten similiar to peoplespace in that 
it can be a front end to any DB, and implement the same API.  It
should be able to read any DBs created by peoplespace, just skipping
over any data that isn't relavent to Kab.  Likewise, if a record is
created with Kab, peoplespace should be able to deal with that as
well, filling it the blank spaces, etc.  The important point is that
they should be able to interoperate.
	However, if Kab is _not_ going to be rewritten, then
peoplespace needs to implement the Kab API.  While it may not map
directly, it needs to be implemented as best as possible.  Some people 
say that KDE should have _one_ address book and everything should use
that.  I disagree.  KDE should have _one_ address book API, the actual 
front-end you use is up to the user.  Some provide more features, some 
less, but all provide a guaranteed minimum level of compatability.  In 
case you haven't picked up on where I'm going with this yet, I think
the solution is a KOM Part that defines the interface to the database
and Kab and peoplespace can both use that and provide snazzy front
ends.  Likewise, KMail (more specifically KMail2), KWord, etc can all
make use of it.  I've been doing a bunch of reading about the
KOffice/KOM stuff and want to start writing something, so if you want
help, now's the time to ask.  KPilot is nearing the official 3.1
release so that should slow down a little and I can spend some quality 
time with Corba.  I'm going to write _something_ using KParts, and
think this is just screaming for it.
	Anyway, the simple solution is I don't think they should
merge, unless Mirko wants to ditch Kab (which I'm sure he doesn't, and 
rightfully so.)  If Mirko wants to keep Kab, and you obviously want to 
keep peoplespace, then they need to work together, and I'm willing to
write the bridge if you want.
	If you think it's appropriate, forward this to the kde-devel
list and people can beat up on it there. -- Dan

-- 8< -------------------

Remeber, the vote is:
 1 - Rewrite Kab merging it with PeopleSpace
 2 - Leave Kab and PeopleSpace alone as is
 3 - Create a common DB format and APi for both Kab
     and PeopleSpace but leave them seperate apps
 4 - Other: your ideas.

Thanks for your time,
-Mike Pilone
mpilone@slac.com

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