[Date Prev][Date Next]
Re: [Fwd: Re: Paged Results and limits]
At 02:34 AM 4/15/2004, Pierangelo Masarati wrote:
>> However, I think we should avoid that complexity for now.
>> And since prtotal is not an orthogonal syntax, I think we
>> should remove it.
>I need to consider your posting with more care, but I basically
>understand your point and find it totally agreeable.
Here's come clarifying comment.
When paging, the administrator may want to change (1) and/or (2).
prtotal is odd in that looks like a new limit, but it's
actually affects an existing limit in a particular case.
I'm think we need to have an orthogonal, general "property"
system (I called it userClass(es) before). A connection would
have a set of properties associated with it at connection
time. Additional properties would be associated at bind
time, for the life time of that bind. Additional properties
would be associated with a particular operation for the
life time of that operation.
Then, access controls would get a new what AND who parameter
called "when". A contrived example:
limit dn=xxx when=(o-c-pagedresults=TRUE) size.hard=N
or with access controls:
access to * when=(o-c-pagedresults=TRUE)
by * when=(o-c-manageDSAit=TRUE) read
Note: One could only allow when= in what or only in the
who, but I think it would more powerful to allow it
in either. Note with limits, the when is part of
the who. One could make it part of the what, but
syntax wise, it would need to be more like:
limit dn=XXX size.hard=H/when=(o-c-pagedresults=TRUE)
The above example hints at an implementation approach.
A connection would have a virtual entry associated with it,
with many 'property' attributes, and the when parameter
just asserts a filter against this entry.
>latter, I think the prtotal (call it whatever and implement it
>as you like; e.g. pageNumber=unlimited) results from user's
>requests. Users used to exploit pagedResults to circumvent size
>limits. While this usage is basically wrong if uncontrolled,
>it may be reasonable if authorized based on the client identity.
>As a consequence, we need to provide that functionality, and
>limits based on client identity are the ideal means, in my opinion.