Re: server-less operation

[Graham B. <gb...@po...>]

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?
> 
>