Hi guys,

I just added the LDAP codec into MINA. We discussed a while back about implementing as much codec as possible in MINA, in order to be able to provide those protocol codec for those who would like to use them (it would be very cool to be able to have something like Ethereal, well, Minareal :)

It works well, messages get decoded and encoded. However, this is far from being enough.

When we think about LDAP, we have two side to consider : the server, which processes Requests, and the client, which process responses. Both should work on top of MINA and its Ldap codec, but we must provide some handler for requests and responses.

I was thinking about adding two interfaces (LdapRequestHandler and LdapResponseHandler) that need to be implemented by either the server or the client. It's not really a big deal, not MINA's problem.

I now have more questions :

Another important thing we have in MINA 2 is a way to demuxing the handlers : right now, in the committed code, we do something like :

        @Override
public void messageReceived( IoSession session, Object message, ReadFilterChainController controller )
        {
            if (message instanceof AbandonRequest) {
                handle(session, (AbandonRequest)message);
            } else if (message instanceof AddRequest) {
                handle(session, (AddRequest)message);
            } else if (message instanceof BindRequest) {
                handle(session, (BindRequest)message);
            } else if (message instanceof CompareRequest) {
                handle(session, (CompareRequest)message);
            ...

It's quite ugly. We could have a filter that associates a message type to a dedicated handler. In MINA 2.0, we had a DemuxingIoHandler handler in charge of each type of message, doing an assication between a type and the handler class.

Q1 : Should we add this class to MINA 3.0 ?

Another important point is that, in LDAP, we may abandon a running request. That means we *must* allow two requests to be processed simultaneously. Of course, we can only process those two requests when they have been decoded. The only way to do that is to inject an ExecutorFilter in the chain after the codec filter.

Q2 : Should we add an executor filter, or should we require the handler to deal with such a scenario ?

Wdyt ?


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Reply via email to