phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] Addbook vs addressbook


From: Jamie Lawrence
Subject: Re: [Phpgroupware-developers] Addbook vs addressbook
Date: Fri, 14 Mar 2003 10:04:29 -0500
User-agent: Mutt/1.5.3i

On Mon, 10 Mar 2003, Ralf Becker wrote:

> Brian Johnson schrieb:
> >I understand that one potential complication of separating the companies 
> >from the
> >individuals in the table format is that it makes the addressbook app 
> >harder to work
> >with those using LDAP
> >
> >I understand that the current LDAP design in addressbook is made to match 
> >a LDAP
> >standard for the storage of contact information
> >

[...]
 
> The only accepted schema for now is the inetOrgPerson and only that is 
> visible in stock LDAP clients like e.g. the mozilla addressbook. 
> inetOrgPerson is basicly the data of a Person including *one* address, 
> phone, fax, mobile, private phone, email, url and a companyname.

And this isn't going away. It is too well entrenched.

[...]
 
> Why would we need up to 2 inetOrgPerson for one person?
> - else your are not able to select private AND buisness mail, phone, 
> fax, address in a stock client

I'd be careful here, if I were you.

I'm involved in several applications that touch upon these issues,
and the mapping is annoyingly complex.

You actually need an arbitrary number of inetOrgPersons to model
possible relations. What if I have a home, an office in city A, an 
office in city B, a role on the board of some other company, and a 
role in, say, several community organizations and open source projects?

If your particular needs don't need to reflect all of that, you can
ignore whatever you want, but some people need to model this.

We're going it by separating people from organizations, expressing
relations and relational attributes between them, and generating the 
LDAP responses on the fly to fit standards based on either context or 
search criteria. Not pleasant, but extremely useful. (as in anything,
there are issues doing this depending on your assumptions about LDAP
environment and specific needs. There are always edge cases.)

(among several other useful properties of this route is modeling 
relations between two or more people, and two or more organizations, 
but that's not related to LDAP.)

Thought I'd throw this out - we've had to put some fairly agonizing
thought into this. HTH.

-j

-- 
Jamie Lawrence                                        address@hidden
"There are some good people in it, but the orchestra as a 
whole is equivalent to a gang bent on destruction." 
    - John Cage






reply via email to

[Prev in Thread] Current Thread [Next in Thread]