directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: Implementing the PagedSearchControl
Date Wed, 10 Dec 2008 05:09:31 GMT
>
> We have to compare the SearchRequest, not the SearchResult. This is dictated
> by the RFC, and it makes sense, as if you change the filter, the baseDN or
> something else, then it's another request.

Sorry, my bad, didn't read carefully enough. This sounds more like a
sanity check on the server side then, rather then a critical part of
the implementation. But if its in the RFC there's no arguing. I
understand the dilema now, but part of me is thinking that anytime the
server normalizes anything (including filters) it should still keep
the original around for comparison (just as LdapDN does) in which case
there wouldn't be a problem.

>> >From the perspective (in part influenced by my VD work, but also
>> driven by encapsulation considerations) I think things are cleaner
>> when the codec (or at least some well defined layer of the codec) does
>> *only* the coding and decoding job, without any expectation of
>> normalization or access to schema information. IMO for the VD usecase
>> the AD server shouldn't expect schema information to be available, as
>> the "real" validation is going to be performed on the ultimate
>> concrete endpoints and the AD server is just acting as a transport /
>> container.
>>
>
> maybe, but from the server POV, this is really a problem. Right now, we
> already do a DN normalization because we need it to manage referrals before
> the request goes through the interceptor chain.
>
> We discussed a lot about VD architectures with Alex, and my personal vision
> is that it's almost impossible to manage correctly a VD without having a
> complete schema knowledge of all the targeted servers. But until I implement
> a VD myself, and face all the associated problems, I may miss something.

I suspect this has a lot to do with whether the VD is actually trying
to persist any data on behalf of the target system (in which case
schema knowledge is definitely required) or simply acting as an
aggreation point (in which case I think the more hands-off it is, the
better). But anyway the major point I'm making is that IMO there
should be a well defined layer in the codec where the data has been
simply endcoded and decoded without any manipulation, if the server
then needs a layer above which normalizes based on access to schema
information that's fine as long as there is an unencumbered layer
below. I haven't got right down into this code in the current trunk
yet, but I think the previous code needed access to the schema by the
codec (for LdapDN / RDNs etc). However, as we've discussed a number of
times my requirements are distinct from the primary ones for the AD
server and therefore it's fine when I need to make custom mods. I'll
now shut-up about VD stuff for good :-)

> No, the way it works is simple: we use the request's thread to handle the
> cursor. Currently, I'm storing the cursor into the session, and restore it
> when a new paged request arrives. It works pretty well. I have not yet
> committed the ocde, because I have some issues with size limit management,
> but I'm almost done (and I was busy those last few days too ...)

Cool, sounds good.
>
> The couple I store in the session is <cookie, pagedSearchCookie> where the
> pagedSearchCookie object contains all the needed information to manage the
> paged search and the current cursor.

Also sounds good.

Thanks

Mime
View raw message