directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [mina] Introducing the New API for 0.9.1.
Date Sun, 22 Jan 2006 16:18:33 GMT
Trustin Lee wrote:

> Hi all,
>
> I refactored MINA API very heavily this weekend, and now it's time to 
> show the result to you.  Please feel free to browse my branch here:
>
> http://svn.apache.org/viewcvs.cgi/directory/sandbox/trustin/mina-spi/
>
> and here's the working examples:
>
> http://svn.apache.org/viewcvs.cgi/directory/sandbox/trustin/mina-spi/examples/src/main/java/org/apache/mina/examples/
>
> Here's the list of notable changes:
>
> * SocketAddress is replaced with IoAddress (org.apache.common )

I see you probably meant o.a.mina.common.

>
> * All bind/unbind/connect operation is performed via 
> org.apache.commin.IoService.  There's no need to instantiate an 
> acceptor  implementation by yourself.  You never access 
> org.apache.mina.transport.* packages anymore.

Nice I like this. 

>
> * 'registry' package is removed.  Instead, IoService does the similar job.
>
Hmmm I liked the registry concept.  It made it clear that you could 
register multiple services with MINA.  But if there is now a better 
mechanism then I'm all for it.  Looks like this bind description string 
does the job below referring to ex1.

> * No more transport-type specific property getters and setters.  Now 
> we use IoAddress properties and the user-defined attributes in 
> IoSession.  For example:
>
> ex1) IoService.bind( 
> "nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",

> new MyHandler() );

This is cool.  Nice step in MINA evolution.  It's like a connector string.

> ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 ) 
> );  // org.apache.mina.common.RuntimeIOException will be thrown if 
> this operation fails.
>
Hmmm why not throw an IllegalArgumentEx ... just curious why this is a 
RtIOEx above.  Could you elaborate?

> * Blacklist filter uses regular expressions to detect blacklisted 
> sessions.

That's a nice feature and it makes sense.

> * Spring integration classes changed a lot due to these changes.
>
What do you think the impact will be to all the protocol providers?

> * Per-acceptor/connector IoFilterChainBuilder is removed.  Instead we 
> could implement IoService to support more attributes.  For example, we 
> could do like this:
>
> IoService.connect( "nio:socket: 
> 192.168.0.1:8080?reconnect=true&reconnectRetry=3&reconnectDelay=10 
> <http://192.168.0.1:8080?reconnect=true&reconnectRetry=3&reconnectDelay=10>",

> new MyIoHandler() );
>
Sorry I did not understand how this example explains the above.  Can you 
elaborate on it?

> Please feel free to criticize these changes.  We're very open to your 
> feedback.  More feedback, better API! :)

Sounds like these changes further reduce the number of lines needed to 
bind a MINA service.  Before we had the following for the echo example:

        Service service = *new* Service( *"echo"*, TransportType.SOCKET, PORT );
        registry.bind( service, *new* EchoProtocolHandler() );

And now we have just this one line:

IoService.bind( *"nio:socket:*:"* + PORT, *new* EchoProtocolHandler(), *new* DefaultIoFilterChainBuilder()
);


I'm seeing the improvement.  I also think managing the filter chain has been simplified: it's

much cleaner now:

Before we had this for adding a logger to the chain:


    *private* *static* *void* addLogger( ServiceRegistry registry ) *throws* Exception
    {
        IoAcceptor acceptor = registry.getAcceptor( TransportType.SOCKET );
        acceptor.getFilterChain().addLast( *"logger"*, *new* LoggingFilter() );
        System.out.println( *"Logging ON"* );
    }

Now we have this:

    *private* *static* *void* addLogger( DefaultIoFilterChainBuilder chain ) *throws* Exception
    {
        chain.addLast( *"logger"*, *new* LoggingFilter() );
        System.out.println( *"Logging ON"* );
    }

It's more concise and clearer without exposing internal details.  A big fat +1 for this.

Overall I think this is a nice jump for the API.  I hope it simplifies the internals as well.
 

Excuse me but I have to ask this :) do we now have this following issue sorted out?

http://issues.apache.org/jira/browse/DIRMINA-166

Really great job T!  MINA keeps getting better.

Alex

P.S. I really recommend those evaluating this change look at the examples since they 
really show the impact of these changes best.  They clarified some points in this 
email.





Mime
View raw message