On Wed, 2003-10-15 at 04:54, Salvador Fandi�o wrote: > Anyway I already have a solution for the callbacks problem that is to > fork a new prprocesso run the LDLDAPuery completely asasynchronously > > But the main problem continues to be how to proxy the authorization > handshaking to the client.
You want to proxy the LDAP bind operation? Using SASL? Well, the "best" and most righteous way would be to rewrite the bind procedure (sub bind in LDAP.pm) -- or if not using bind, any other appropriate procedure to do something else instead of invoke your callback. You could also do this through subclassing Net::LDAP. Another option, and one I use for an application I'm working on, is for a different problem. Basically, you would do your Select-check ($sel->can_read(0)) inside the callback. Evaluate the operation performing the callback inside an eval, and start an alarm clock. If the client takes too long to proxy, die. This is bad. For a lot of reasons: Most notably that client "B" can stall the completion of proxying for client "A". It works for the application I am using because both client "A" and client "B" are the same actual client (and they're already trusted)- and if they really want to slow eachother down, then hey, it's their experience. But I don't think this is the best path for you. I don't understand why you need to fork a new process though. It takes less time to build-out the LDAP message and put it onto the wire than it does a context switch on many systems. If you were really running into performance problems, I would (and did for my LDAPDNS nameserver) write my own LDAP client [and in my case, also the ASN.1 routines] and multiplex the communication that-way. Maybe I do not understand what operation in Net::LDAP has this kind of callback. I'm not aware of any (besides the SASL callback) where the callback actually has to do "anything" before the operation can be completed. Or maybe you're running on a system where $sel->can_write is critical to use...
