[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: need some help

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.

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 (slim@us.ibm.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 <slim@us.ibm.com> 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 <slim@us.ibm.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
> appropriate.
vadim <vadim.tarassov@swissonline.ch>