Stanford has been looking into implementing the value-sort attributes
overlay, and realized some problems with using it, if the attribute to be
weighted is also indexed and you will be using weights. Primarily, the
problem stems from this:
The unweighted form of the data could look like:
suaffiliation: stanford:staff
suaffiliation: stanford:faculty
etc
The weighted form of the data looks like:
suaffiliation: {2}stanford:staff
suaffiliation: {1}stanford:faculty
This means if you use the data for indexing (in particular, in my case, eq
indexing), it will no longer be possible to use filters of the type
(suaffiliation=stanford:staff). Which is problematic when many
applications do that very thing (and internal ACL's use it as well).
I thought a potential solution (not possible at this time, per Howard)
would to be able to support something like multiple indices (sub indices?)
that would actually index the data in both its weighted and unweighted
form, if the val-sort overlay was present. It is also something I thought
could be potentially useful for other overlays (how, I'm not sure). But
the ability to have indexing behave differently based on different factors
does seem potentially useful.
In addition, things get more complicated when telephoneNumber (and things
using its syntax) are involved. Mostly because {}'s are not valid
characters per its syntax, meaning you can't sort the attribute via
weights. The ability to tweak SYNTAX based on overlays I guess would be
the solution, but sounds ugly.
Anyhow, just a set of thoughts, I don't know how practical implementing
such a thing would really be.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Tuesday, October 03, 2006 7:23 PM +0000 kurt(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/schema
>
> Modified Files:
> core.schema 1.88 -> 1.89
>
> Log Message:
> Incorporate a bit of text from RFC 4524, just to make a point regarding
> ITS#4693.
The general problem is that things that are copyrightable are not generally
distributable in free distributions (i.e., debian), which means that they
then cannot distribute core.schema with the OpenLDAP distribution if you
make the copyright statement applicable. They already strip out the RFC's
since they also are non-free.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Ralf Haferkamp wrote:
> Now I am wondering what would be the best way to inject that original
> OperationRequest onto the target server. Currently I initialize a (fake)
> connection with connection_fake_init(), register a response_callback and feed
> the originalRequest (still undecoded) directly into the do_*() functions
> (e.g. in case the originalRequest is of LDAP_REQ_MODIFY I call do_modify()
> directly). Is this the correct way of doing things, or am I abusing things
> here in ways that they weren't intended for? Is there a better way to feed
> the original request into the target server?
>
> BTW, is somebody else working on that code currently? I'd like try to avoid
> double/unneeded work.
>
Ralf,
in principle I should be working at that, but I haven't been able to
dedicate any time to it essentially since the time I added distproc.c to
back-ldap. Directly calling do_*() functions is what I planned, but I
didn't work out yet whether it's just safe to call them that way or
not. One issue I wanted to solve at that time was essentially
procedural: how much are we supposed to stick with that expired ID? I
know the original Author was looking for someone to pick up from where
he left, and I had a couple of questions (and suggestions) I'd like to
see in place.
By now, if you're doing anything you consider "decent", please feel free
to commit it. It's not going to get into release any soon, so even
things that do not immediately work may be acceptable. I'd be glad of
reviewing it, and contribute as much as I can.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
