[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