[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6247)
masarati@aero.polimi.it 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.