Since this adds nothing in terms of interop with other clients, I 
don't see the advantage. horde/scripts/ldap/horde.schema adds the 
turbaType and turbaMembers attributes which support Turba's existing 
group implementation; this works fine. So I'm not inclined to commit 
this.



I've added the error check to browse.php, thanks. Better error 
handling is great but please don't mix it up in other patches. Also, 
please always submit enhancements against HEAD.

Well, I don't see any better standard to store groups of contacts in 
LDAP. Unfortunately I found no client fully supporting groupOfNames 
:-(. But those clients I tested (outlook, mozilla*, evolution, 
kaddressbook) can't store / read group of contacts (lists) into LDAP. 
Only Outlook can read groups, but shows no members (there are several 
discussions about that on the internet with no result).
this was patch against turba-h3-2.0.3-rc1
because target can be of type PEAR_Error and then $target->isGroup() 
is fatal. But anyway in Turba the error handling is implemented only 
partially.



Anyway, in our case changes to Object.php and browse.php are not neccessary.
as you wish ... done
In groupOfNames can be stored any references. The syntax of every 
reference must be valid DN.
No, you can't. But I don't know the current way. I found no 
sources.php example using LDAP and contact lists.



-------------------------------------------------------------



I've prepared a new patch. The only modified file is ldap.php. In 
sources.php one can indicate using of groupOfNames by setting 
$params['use_groupOfNames'] = true;



Moreover $map must contain theese fields:

         '__key' => 'dn',

         '__type' => '__type',

         '__members' => '__members',

         'objectclass' => 'objectclass',

         'member' => 'member',

         'name' => 'cn',



If anyone has any more suggestions to this patch then please try to 
implement it on your own or write a comment here :-)

Is the groupOfNames objectclass standardized enough to hardcode like this?



If so, I don't mind the patch in general. I'd like to see more 
comments for each change block, and to see it cleaned up to follow 
CODING_STANDARDS. You should also provide a patch for 
sources.php.dist, instead of a new sources.php file.



Also, the change to Object.php is duplicative, and why the change to 
browse.php?



If all the changes were localized to the LDAP driver I'd feel better 
about it. Would using this method completely replace the existing 
method for storing groups in LDAP? What kinds of ids do other clients 
store in a groupOfNames object? I'm guessing we couldn't store ids for 
non-LDAP contacts this way, which we can do the current way. Would it 
be possible to introdue groupOfNames as a different kind of group, or 
as a read-only interpretation of what's on the LDAP server already?

Hello



I've implemented support of lists (groups) of contacts into LDAP 
backend. Implementation is not very clean because of the Turba driver 
architecture. There can be no synthetic (derived) atributes and Turba 
expects that the contact Object and list Object differs only in the 
value of some __type attribute. But LDAP is not the case. The LDAP 
groupOfNames objectclass differs a lot from *person.



The implementation as I have written has therefore some harcoded 
lines. Maybe someone could improve that or give me a clue how it could 
be made better. Anyway, it works for me and I use it :-)