Re: server-less operation

[Clif H. <ch...@po...>]

I think this is a good idea.

Clif


Graham Barr wrote:

> This sounds like an excellent idea. But I think it should be a sub-class
> of Net::LDAP.
>
> In fact, if it was a package that understood the data structures
> passed to Convert::ASN1. Then it could have many uses.
>
> Your subclass you mention could just call it instead of encoding
> with Convert::ASN1. But we could also write a simple server that
> could be used for testing within the distribution.
>
> Graham.
>
> On Thu, Nov 15, 2001 at 05:30:38PM +0000, John Berthels wrote:
> > Hello folks,
> >
> > Does anyone see any utility in adding support for Net::LDAP to query a
> > local LDIF file as opposed to a directory? This would be for testing
> > purposes, and I think could be made to work like this:
> >
> > - read-only. All add/modify etc operations fail
> >
> > - each search operation could simply re-scan all entries in the LDIF file
> > sequentially and decide if the entry matched the search criteria. Then
> > either add to the search result and/or fire any callbacks.
> >
> > Of course, this could be optimised but that isn't really the point.
> >
> >
> > The point would be that for the (reasonably large?) class of problems
> > which require read-only LDAP access, you could write and test Net::LDAP
> > code against an LDIF image of a directory.
> >
> > Would patches to implement something like this be accepted (or would this
> > be better as a seperately maintained subclass of Net::LDAP)?
> >
> > Does anyone see problems in doing this which I have missed [*]?
> >
> > Or is something like this already implemented and I've not noticed?
> >
> > regards,
> >
> > jb
> >
> >
> > [*] - complications could include:
> >
> > a - authentication (probably either support simple auth only or always
> > succeed)
> >
> > b - starttls [again probably just fake success]
> >
> > c - I haven't really thought through how complex the 'does this entry
> > match these search criteria' decision would have to be. Filters can be
> > complex. Will I need to handle different encodings of DNs and attribute
> > names?
> >
> >

--

Regards,

Clif Harden                                          ch...@po...