directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keheliya Gallaba <>
Subject Re: LDAP diagnostic tool - GSoC 2010
Date Mon, 24 May 2010 09:04:54 GMT
Hi Seelmann,

On 23 May 2010 15:19, Stefan Seelmann <> wrote:

> Keheliya Gallaba wrote:
> > Hi all,
> >
> > Thanks very much for your descriptive feedback. I modified the
> > architecture diagram [1] according to your suggestions. As Emmanuel
> > pointed out, I'm hoping to get an idea from apacheds-protocol-ldap
> > subproject for intercepting messages coming from the client and using
> > Apache LDAP API to send the modified messages to the server. I think
> > responses coming from the server need not to be modified. They can be
> > just captured for logging purposes, and redirected to the client
> > unmodified.
> Why not modiying or filtering the response? I think this is an essential
> feature. In you proposal you already descibe several use cases.

I initially thought it wont be necessary to modify the responses coming from
the server, since I assumed they are well-formed. But now I understand there
will be several use cases, like removing certain attributes and rewriting
DNs, of entires in the responses.

> Can you please also describe what the "Validater" (should I be
> calledValidator?) and "Debugger" are used for?

Oh, sorry about that spelling mistake. I thought of validator as the unit
for identifying messages that are not in the proper format. Debugger is for
changing messages in real-time and sending them to the destination.

> In 3. you write "for later ... playback", in that case it must be
> possible to read the messages (could be request or response messages)
> and send them (maybe modifed) to the server or client.
> Having said that I have a more general design in mind:
> - a message source (the TCP layer or the storage when replaying messages)
> - a message target (the TCP layer)
> - a message processor in between that is used for validation, logging,
> debugging, modification.
> The message processor could use the interceptor pattern (we already use
> the interceptor pattern in the server). Then the validator, logger,
> debugger, etc. can just be implemented as an interceptor.

That sounds clear. As I understood in this approach, except the message
processor other modules treat requests and responses, nearly in the same

> What do others think?
> Kind Regards,
> Stefan
Looking forward for guidance from you all, to start with development.

Thanks and regards,

Keheliya Gallaba

View raw message