[turba] Re: Contact Management

[James Tavares]

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


> Quoting James Tavares <jtavares@loa.com>:
>
> > I'd like to move progess along on turba's group support. It's important
to
> > me (I hacked it into 2.2.4 in the worst way.)
>
> Great! :)
>
> > I'd like to make one suggestion...If I'm to code this, I'd like to add a
> > table so as I could support Groups within Groups.. Basically:
> >
> > CREATE TABLE Turba_Groups_Groups (
> >     parent_grID varchar(32) NOT NULL,
> >     child_grID varchar(32) NOT NULL
> > );
>
> Sure - or we could just add a object_type field to Turba_Groups, so:
>
> Turba_Groups {
>   group_id,
>   owner_id,
>   object_id,
>   object_type
> }
>
> (groups _are_ objects, after all).

Perfect. I'm just as happy doing that... I wasn't sure how you'd feel about
it, so that's why I suggested the more straightforward "Relational Database"
method of an extra table.

> > What is the contents of object_ID and owner_ID?
>
> object_ID is just a unique identifier - it's the "key" field for the
object
> (like DN is in LDAP). owner_ID is the Horde username of the person who
owns
> that object.
>
> > Do you guys have any reservations about using Auto Increment columns?
> > Personally, I think they would make perfect _ID's to link all these
> > tables.....
>
> Yes: they are rather specific to mysql. We can use PEAR's sequences if
> necessary. Also, try not to think too specifically to sql; LDAP isn't a
clear
> fit for groups, but it should be possible to have dbm-based groups, for
example.

I understand your argument on the auto increment stuff, and I noticed you
have a makeKey function that you use for this sort of thing, which is more
that perfect... I'll talk more to LDAP and groups below:

> Speaking of which, it seems like it might make sense to have a seperate
> Turba_GroupDriver:: hierarchy, since there's no particular reason to say
that
> they have to be stored in the same place as the actual contacts (and since
LDAP
> groups seem a bit hairy, it'd be nice to let people make groups of LDAP
> contacts). So that gets us to:
>
> Turba_Groups {
>   group_ID,
>   owner_ID,
>   object_ID,
>   object_Type,
>   object_Source
> }
>
> ... for SQL, anyway.

I think that LDAP could store group information:

cn=objectID,ou=jtavares@loa.com,ou=objects,o=myOrg
objectType: group
name: myGroupsName
memberObjectID: SomeOtherGroupID1
memberObjectID: SomeOtherObjectID1
memberObjectID: SomeOtherObjectID3

cn=SomeOtherGroupID1,ou=jtavares@loa.com,ou=objects,o=myOrg
objectType: group
name: myOtherGroup
memberObjectID: SomeObjectID4

cn=SomeObjectID1,ou=jtavares@loa.com,ou=objects,o=myOrg
objectType: object (contact?)
name: James Tavares
address: Blah
email: jtavares@loa.com
....

Of course, to make administration eaiser we could remove ou=username from
the DN (otherwise a leaf has to be created for each user) and add it as an
attribute type of ownerID:, but I like having the ability to restrict the
scope of the search the narrow base that is the user's address book.

We could also divide objects and groups into two seperate bases:
{ cn=SomeGroupID,ou=groups,ou=jtavares@loa..com,o=myOrg
  cn=SomeObjectID,ou=objects,ou=jtavares@loa.com,o=myOrg
 }

OR (based on method of organization)

{
cn=SomeGroupID,ou=groups,o=myOrg
ownerId: jtavares@loa.com

cn=SomeObjectID,ou=objects,o=myOrg
ownerId: jtavares@loa.com
}

My first set of LDIF style examples are my prefered method for storage in an
LDAP database. Just feels "clean" to me. Feel free to talk me out of it. I'm
a pretty open guy.. I guess thats why I included all the other possible
options.. hehe...

So, I guess what I'm saying is, I don't think a different driver should
exist for Groups. I kind of see a group as nothing more than an object with
children (except for the fact that a group has no real properties like an
object does. Which, in a SQL world, makes it inappropiate to store in the
same table as other objects. But in LDAP, why not? there's no unused space,
no strict definitions... )

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:

member1: objectID_In_LDAP
member2: anotherID_In_LDAP
member3: someGroup_In_SQL

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?

Does my reasoning make sense? I know that in general you like to make things
rather robust, so I might be missing something about a possible future
feature with Turba that my implemenation could be conflicting with. (I.e.,
the fact that you call an "object" what I would call a "contact" or "address
book entry" possibly means that there is something else turba could be
serving up one day? hmmmm?   :) )

-James

---------------------------------------------------------
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/