Re: [Phpgroupware-developers] Addbook vs addressbook

[Brian Johnson]

Jamie Lawrence (address@hidden) wrote:
>
>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
>

These concepts also apply when trying to sync contact data to pda devices that
always seem to be a single record

I think everyone is agreeing that a better db layout is needed (multi 
dimensional),
and the code needs to be able to provide a view of the data in a one 
dimensional format

What can I do to help?

--
Brian Johnson

This is where my witty signature line would be if I bothered to edit this line 
:)