[email protected] wrote: >> Hi, >> >> I've just uploaded an updated version. >> >> Changes regarding schema: >> - Added EQ-Matching rule to both nowNot{Before|After} attributes >> - changed attribute nowNotAfter from single- into multi-value >> >> ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz >> > > In order to make your contribution useful to others, I think you should > definitely separate comparison with respect to current time from the rest > of what you need. > In this sense, special matching rules to compare generalizedTime-syntax > attributes with respect to "now" have nothing to do with the declaration > of specific generalizedTime-valued attributes. > I've already thought about this. I'm in two minds about that.
> As I mentioned in an earlier posting, any generalizedTime-syntax attribute > can use your special matching rules by way of the extensible filter > mechanism, regardless of having any matching rule in their definition. > I thought, that by not assigning any matching rule the EQ/LE/GE comparison is not possible at all. That's the behavior I would like to achieve regarding the two minimum-attributes (regardless whether the probable separation of matching rules and attribute definitions - disscussed in the above paragraphs). Yesterday I've noticed that without an EQ-Matching definition I was not able to add an additional value in case of a multi-valued attribute definition (so I added EQ-Matching again). I have to admit that I do not understand this in detail. I also have not investigated in deep... > Moreover, attributes can already be defined using slapd.conf/back-config, > so there's no need to hardcode them in your module (except, possibly, for > your specific needs, but this makes the module less general and useful to > others). > The oc/attr definition is for demonstration purposes only (I though it's more compact to include this "demo" and implement it the most restricted way regard data privacy (especially disallow querying LE/GE for both attr). Problably I'll separate the demo into an extra schema file. > But > the real reason is that "exactly equal to now" makes little sense as "now" > is evanescent: you have no control about exactly when your matching rule > hehe that relativistic effects I already had in mind before implementing this kind of matching rule. That's the reason I originally followed the approach to manipulate the search requests' filters. This approach could assure to make use of the "same" now (op->o_time) for all entries. By using the matching rule (especially in combination with the filter= statement in ACLs) "now" will become some kind of "time distance" instead of a point in time because a search' results get evaluated sequentially by test_filter(). In worst case the second have of a billion search entries are valid during the search but get "invalid" during acl processing, because time move's on... ;-) On the other side comparing the lines of code of the matching rule approach to my previous pre-alpha overlay's lines of code, this matching rule's implementation is about 10 times smaller... > will be evaluated, so if the difference between "including now" or > "excluding now" is crucial, then there might be something flawed in the > policy you're trying to implement. > Ok, this in mind I'll at least reduce the matching rules to two but the problem (now == time_delta) still exists. > Getting more into implementation related aspects, I think you should > really ignore the asserted value, rather than check it's equal to the > Epoch. I initially suggested to put the Epoch as the asserted value in > order to use some clearly recognizable, yet valid, value. But this should > be a matter of style rather than a requirement of the matching rule. > I regard to some kind of future formal specification I thought about this, too: in my opinion it seems to be "unnatural" to search (assert) a non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But probably that's really only a matter of style. > With respect to OID assignment, as soon as your contribution is considered > of general usefulness, it could receive a temporary OID out of OpenLDAP's > experimental branch. If you intend to formalize this set of matching > rules somehow, you should apply for IANA assignment of an official OID. > > Note that I'm not encouraging nor discouraging you in this sense. > I'm currently thinking about this... Thanks for your feedback the discussion is very interesting and helpful.
