[turba] Re: Contact Management

[James Tavares]

----- Original Message -----
From: "Chuck Hagenbuch" <chuck@horde.org>
To: <turba@lists.horde.org>
Sent: Monday, April 23, 2001 2:18 PM
Subject: Re: [turba] Re: Contact Management


> Quoting James Tavares <jtavares@loa.com>:
>
> > I think we could make a firm stand on a single local TurbaSource being
the
> > exclusive provider for all contacts and groups, within the realm of a
> > personal address book. Also, are we looking to make cross-database
links.
> > I.e., an LDAP Group having members as follows:
>
> Yes.
>
> > I really don't see a viable use for this, and really would rather not
> > thinking about implementing it (especially since it would pretty much
void
> > my LDAP proposals above) I mean, does someone really need to link
between
> > TWO local address books? I can see HAVING two different local address
books
> > and using both, but linking between them? That seems like extra bloat
for
> > me.. Your thoughts?
>
> Example: my company has an exchange server that I can search through LDAP.
But
> I can't add my _own_ entries through LDAP. So I'd like to be able to
create
> local groups in my personal addressbook that refer to the entries in LDAP.
>

Very good point. Okay... Here's where we stand, with a major modification to
my previous LDAP suggestion:

FOR LDAP STORAGE:
A contact is stored within:
cn=objectID[,cn=user@domain],ou=turba_objects,o=myOrg
name: James Tavares
attr: value

So far, everything normal. Here's the LDAP change... Instead of storing the
object ids in an attribute, we expand it to a new tree branch:

To extend the object with group members, use _ONE_ new tree branch (never
more than one additional level!):
cn=memberEntryID (YES, a new unique
value...),cn=objectID[,cn=user@domain],ou=turba_objects,o=myOrg....
memberObjectID:  sourceChildID
memberObjectSource: sourceChildID2
memberObjectOwner: (do I smell future expansion? -- this would be the owner
of the TARGET member, which is not defined here.)

This offers the most flexability. What if we in a couple months sourceName
and sourceID are not unique enough to describe an address book entry? You
could, for example, create a group whose sole member is a group that exists
in somebody else's control. This could be accomplished through a "Public"
attribute/column in the contact/group list for internal sources...

I.e., Manager Joe maintains a group called "Workers" that has as its members
contacts who work for him. He enables the Group as public, and emails it
(how convient!) instructing his workers to add a group whose sole member is
his own "Workers" group. This way, whenever he modifies the Workers group,
all his workers have the latest copy.

A novel idea that could be implemented some day.. The point is, that with
the data stored like it is above, it COULD be implemented. The same goes for
SQL:

FOR SQL STORAGE:
List all contacts and groups line by line in turba_objects
    (standard -- in use today)

List all map entries in turba_map:
    MemberEntryID
    ObjectID (The Parent)
    MemberObjectID (The Child)
    MemberObjectSource (from sources.php)
    MemberObjectOwnerID (see description above....)
    ...Columns could be added in the future.

What do you think? This allows for both backends to support contacts,
groups, groups as members of other groups, and groups with contacts/groups
that exist outside of the current address book (your exchange server
example.), (and possibly one day linked to addresses that belong to other
people..) Hell, one could write a driver to directly interface with Outlook
Express Address Book files (I understand an import project is underway, just
giving a suggestion..) and have people upload them.

I think for the LDAP stuff it may be worthwhile to seperate the "local
address book" driver from the "public directory" driver.. This would allow
us to extend the local stuff to be more flexible, while the "public" stays
standards based (Netcenter, etc..)

Btw.. code is coming Very Soon.

---------------------------------------------------------
James Tavares <jtavares@loa.com>
Sr. Data Network Engineer
Log On America, Inc.

Ph: 1-401-459-6294
Fax: 1-401-459-6580
Web: http://www.loa.com/