Re: [Phpgroupware-developers] HEAD setup app

[Alex Borges (lex)]

El vie, 21 de 02 de 2003 a las 03:31, Ralf Becker escribió:

> > 
> > The second meaning i should be able to plug phpgw into any existing ldap
> > directory with person, orgperson, inetorgparson entries and to search
> > using phpgw as a frontend and everything should be transparent and
> > exactly the same as if the contacts where on sql. I should also be able
> > to sync with an existing ldap directory and trun its entries into phpgw
> > contacts. 
> 

> So we can NOT change the field or the db-format of one entry containing 
> the company as well as the personal data, as we would violate the 
> existing LDAP-schemas.
> That means an approach as addbook uses, to split the company and the 
> individual entry (normalize the db) would not work (at least not for LDAP)

Okay, at the risk of biting my own toe here, what i see is that the
existing ldap schemas for phpgwcontact should die, die, die. I propose a
full rewrite based in the existing person, orgperson and inetorgperson. 

The technique for using the same api working on ldap and sql still
holds, but the underlying apporach might not.

For example, for the schemas mentioned, organization is indeed just a
text field. And what we want is to have a real relationship like the one
in addbook. What i think maps more naturally to ldap is turn our sql
organizations (as addbook does tham) into real ou's. In the end, its a
hierarchical relationship isnt it?

I dont know. I havent studied the problem thoroughly. But i think im
safe saying that:
1) full ldap interoperability should be a must  
2) The problem you expose here (we wont be able to implement the
addressbook the right way.....) i think can be worked arround in another
layer. 
3.- So yeah, maybe making each organization a different ou in ldap wont
be very efficient and probably will be cumbersome (how can i have 1 guy
belong to three different organizations.....maybe copy his record to all
three...etc.) The thing is that this is an implementation rpoblem in
ldap and shouldnt worry us right now since we are only defining features
for now. 

The features such as a one to many relationshipo for orgs -< people
should hold...and if thats a bitch to implement in ldap and is really
slow, then we are a slow ldap client...BUT we interoperate...and maybe
we can have our cute fast sql addressbook and if you switch to ldap then
its all slow and sluggish when you have many orgs and many people in
many orgs...etc.... BUT we have the code to convert that into ldap
periodically..... bottom line.... we need to interoperate. 

To ignore non-web/non-phpgw clients of central corporate directories
wont help this project at all....we just need to meet somewhere in the
middle to provide all the cool features we all want AND a path to
interoperate with standard ldap schemas.

At the very least, we should be able to import to phpgw contact schemas
the data in the mentioned standard schemas. As it stands now, we provide
no non-programmer path to integrating phpgw to an existing ldap-based
corporate directory.
 

> .
> 
> As far as I see, we had to duplicate the company entries in each 
> individual entry and change them all, if someone edits the company data 
> of one of the entries. This is not realy a good concept, but might work 
> if the changes are ONLY made from within phpgw and we should use this 
> approach only in the LDAP-contacts-class and not in the SQL version.
> 
> None of that would influence the display of the contacts as many 
> individuals belonging to one organization (as eg. addbook does it), as 
> this can be done internaly with a query.
> 
> Maybe someone the more LDAP knowhow (knecke, ...) can comment on that.
> 
> > 
> > Those are really my only priorities right now... so, this also calls for
> > discussion with other contact backend developers like ralph and 
> > knschke (sigh, will i ever get it right)
> > 
> > Lex
> > 
> > 
> > 
> >>
> >>_______________________________________________
> >>Phpgroupware-developers mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> > 
-- 
Alex Borges (lex) <address@hidden>
Step One Group