[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: OpenLDAP 2.5
From:       Daniel <deepee () gmx ! net>
Date:       2010-04-28 18:43:01
Message-ID: 4BD881B5.6090607 () gmx ! net
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]