[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP 2.5
Howard Chu wrote:
These are the things I'm interested in. But as always, this Project is
driven forward by the particular interests of each individual
contributor. If you have other ideas you want to pursue, speak up.
Hi Howard,
first of all many thanks for the chance to exert influence on the future
development!
I cannot estimate how complicated it would be (or if it's at least
possible somehow) to provide access to an operation's details during
normalization, but I would appreciate to see such a kind of possibility
in 2.5. My question/demand is related to "server side current time
matching (ssctm)" which I'm from time to time (every now and then ;-))
experimenting with. ssctm among other things is planed to provide
support for filter statements, like for example (timestampAttr>=NOW)
etc. pp.
My (currently very experimental) prototype expands the above example
filter's assertion value during its normalization whereas the current
time in generalizedTime syntax is determined on-demand (using a system
call). The result is used for the later matching operation(s). There are
two points I'm currently don't know how to proper solve without many
changes regarding 2.4:
- In my opinion it would be a general advantage to take the constant
operation's time-stamp "op->o_time" instead of using a system call, but
there is currently no (at least I'm not aware of any) chance to access
an operation's details from within the normalization (or matching rule)
functions.
- Additionally some kind of reliable evaluation of filter-lists, like
for example: (&(timestampAttr=NOW)(timestampAttr=NOW)) is needed, too.
In my current understanding of the 2.4 API's filter normalization
processing each filter-list's element gets normalized independently and
thus potentially sequentially (have not investigated/tested in deep).
With the above on-demand system calls the time-stamps resulting from the
equivalent assertion values could differ which could unexpectedly lead
to no, too little or too many matches (depending on the logical
combination and the filter-list's details. The above example is just for
demonstration and represents the most obvious potential failure scenario).
Many thanks for your feedback.
Best regards
Daniel