sebastien.georget@sophia.inria.fr wrote:

>Full_Name: Sebastien Georget
>Version: 2.2.20
>OS: RHEL 3
>URL: http://www-sop.inria.fr/dream/personnel/Sebastien.Georget/contribs/expandUrl-0.2.c
>Submission from: (NULL) (138.96.66.17)
>
>
>This small overlay follow URL attributes during a search operation. It was
>written to define (merge) groups this way :
>
>   dn: cn=test,ou=Group,dc=test
>   memberURL: ldap:///cn=test,ou=Group,o=org1,dc=test
>   memberURL: ldap:///cn=test,ou=Group,o=org2,dc=test
> 
>   dn: cn=test,ou=Group,o=org1,dc=test
>   memberUid: bob
> 
>   dn: cn=test,ou=Group,o=org2,dc=test
>   memberUid: alice
>
>
>The overlay is configured with the following directives in slapd.conf :
>   moduleload expandUrl
>   overlay expandUrl
>   expandUrl dn attr1 attr2
>
>The 3 parameters are :
>  - dn : the overlay will only operate on this dn
>  - attr1 : the overlay will look for URIs in this attribute
>            only the dn part of the uri is used
>  - attr2 : if target URIs contain this attribute the
>            values are merged in dn
>
>Once configured the result of ldapsearch -x -b "ou=Group,dc=test" is :
> dn: cn=test,ou=Group,dc=test
> memberURL: ldap:///cn=test,ou=Group,o=org1,dc=test
> memberURL: ldap:///cn=test,ou=Group,o=org2,dc=test
> memberUid: bob
> memberUid: alice 
>  
>
We developed a similar implementation at SysNet, initially based on a 
customer's request, which seems to be a bit more general, since it 
determines if some emtry's URL-valued attributes should be expanded 
based on the objectClass of the entry, and honors stuff like the 
intersection of the attribute list in the URL with the requested 
attributes, and applies to compare as well.  I'll check out if I get 
permission to post it to the ITS, in case anyone finds it useful.

Ciao, p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

ando@sys-net.it wrote:

>We developed a similar implementation at SysNet, initially based on a 
>customer's request, which seems to be a bit more general, since it 
>determines if some emtry's URL-valued attributes should be expanded 
>based on the objectClass of the entry, and honors stuff like the 
>intersection of the attribute list in the URL with the requested 
>attributes, and applies to compare as well.  I'll check out if I get 
>permission to post it to the ITS, in case anyone finds it useful.
>
Sounds like you have a more thorough version of the dyngroup overlay. It 
would make sense to merge or replace that, if you can. I started writing 
a search expander for the dyngroup overlay but never finished, if you 
have something working already I won't bother...

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> Sounds like you have a more thorough version of the dyngroup overlay. It
> would make sense to merge or replace that, if you can. I started writing
> a search expander for the dyngroup overlay but never finished, if you
> have something working already I won't bother...

OK, I'm about to release it.  There might be room for further development,
especially in the area of the compare, which could benefit from
short-circuiting it into the response callback of the inner search.

Note that the dynamic group expansion is rather a side effect of this
overlay, so, despite implementing the feature, it might not be optimal. 
At the moment it's called "dynlist", and its suggested usage is based on
"groupOfURLs" and "memberURL" as defined in "dyngroup.schema".  I'd commit
it to server/slapd/overlays with the current name; eventually, if we merge
it into the dyngroup it can take that name, or live of its own.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

> OK, I'm about to release it.  There might be room for further development,
> especially in the area of the compare, which could benefit from
> short-circuiting it into the response callback of the inner search.

It's now in HEAD.  There is yet need for some work on compare.  In fact,
compare was designed to work on the results of an underlying search with
expansion.  This causes two orders of problems:
1) it's inefficient, because the search needs to complete before compare
can take place, but compare could end as soon as a positive match occurs;
2) it doesn't work when the overlay is stacked on top of the frontend (the
search works fine, fortunately).
The main reason compare was placed on top of a search was to reuse most of
the code; I'll have to rework that a bit, but I think it can be done
without adding excessive duplication.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

moved from Incoming to Contrib

changed notes
changed state Open to Suspended

changed state Suspended to Closed

moved from Contrib to Archive.Contrib

superseded by dynlist?