[Date Prev][Date Next]
Re: need some help
At 10:00 AM 12/22/2005, vadim wrote:
>Hallo Kurt, everybody,
>please excuse me if I become annoying. May I allow myself one more
>question, namely, is it possible to implement component indexing in a
>proper (according to Howard) way in terms of module (or overlay) without
>modifying slapd or backend code? If it is possible, I would probably try
>to get component matching to work, otherwise not.
In theory, component matching can be implemented as just
a module as it just a set of syntaxes and matching rules.
However, in practice, that is, for performance, it's likely
that an implementation will need to modify both the
frontend and backends. For instance, indexing today is
quite backend-specific. So, it is likely that indexing
to support component matching would also be backend-specific.
And modification of the frontend is likely necessary to
avoid re-parsing the same value multiple times
in evaluating complex component assertions.
Note that the same applies to extensible matching in general,
and in fact, all matching. For performance reasons, both
frontends and backends are involved in making matching
Now if we had a general module-based framework for extensible
matching, including facilities to storing rule specific
normalized values, indexing and such, then likely component
matching could be implemented as a module using that framework.
But that framework doesn't exist today.
>Thanx a lot and best regards, vadim tarassov
>On Thu, 2005-12-22 at 07:14 -0800, Kurt D. Zeilenga wrote:
>> At 02:20 AM 12/22/2005, vadim wrote:
>> >Hallo everybody,
>> >It looks like there is a couple of problems with component matching
>> >module (see ITS 4112 and 4270). I have sent message to the email address
>> >mentioned in the code <slim@OpenLDAP.org>, and got following back:
>> >User slim (email@example.com) not listed in Domino Directory
>> >Therefore, may I ask you one several beginner's questions?
>> I note that software use questions should really be discussed
>> on the software list, but as some of this touches on development,
>> I'll respond to all (though in doing so, I target my response
>> to 'developers' not to 'users').
>> >2) Since I do not know yet what is OpenLDAP server module, could you
>> >please tell me why <firstname.lastname@example.org> has developed a module? Why not
>> >overlay? What is the difference between modules and overlays? In your
>> >opinion, should it be implemented as module or overlay?
>> Every overlay is a module. But not all modules are overlays.
>> Component matching, in the end, might be best implemented
>> natively. I doubt all of the functionality can be implemented
>> without modification of the slapd(8) and/or backend code.
>> >1) Is there any documentation about OpenLDAP server modules? I guess it
>> >should be a DLL, which must implement particular well defined
>> >interfaces. I guess at different stages of the request processing slapd
>> >invokes these interfaces. Is it described somewhere? I suppose you will
>> >tell me, that the best documentation is the source code. Could you
>> >please nevertheless point me at that part of the source code?
>> As indicated in my above answer, as overlays are modules too,
>> much of the documentation about overlays applies generally to
>> all modules. In particular, how to build and load them.
>> Only use is a bit different. Overlays configuration information
>> has to be provided relative to the backend configuration information
>> that its overlaying. Other kinds of modules can generally go
>> anywhere, but usually go in a global section of the configuration.
>> Documentation is in the usual places.
>> >3) Regarding ITS 4112 ... Could you please point me at source code which
>> >shows, how this thing should be implemented from your point of view?
>> I don't think there is source code which implements the indexing
>> consistent with Howard's (correct) point of view. Which is why
>> there is an ITS.
>> >4) Do you know, why <email@example.com> has chosen esnacc to decode BER
>> >encoded ASN.1 structures? I know one project, namely
>> >http://lionet.info/asn1c/, which seems to be in much better shape
>> >compared to esnacc.
>> esnacc was used by the first development team (not Sang)
>> on my recommendation. asn1c was not available at this time.
>> When Sang started his work, esnacc was still the most viable
>> choice, hence I recommended esnacc again. IIRC correctly,
>> asn1c was just appearing on the scene at this time. It
>> wasn't suitable at that time.
>> >And why he is writing that one should use esnacc from OpenLDAP ftp server?
>> Because OpenLDAP extensions to esnacc are required.
>> Not only was esnacc modified to support GSER, esnacc
>> was modified to produce matching routines in addition
>> to encoders/decoders.
>> >5) May I continue to ask such questions on this list?
>> Well, it's best that further software use questions, such as
>> "How do I build this?", be directed to the software list.
>> However, if you have a development question, this list is