directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter royal <pro...@apache.org>
Subject Re: [mina] Introducing the New API for 0.9.1.
Date Mon, 23 Jan 2006 15:50:57 GMT
On Jan 22, 2006, at 6:51 PM, Trustin Lee wrote:
> 2006/1/23, peter royal <proyal@apache.org>:
> On Jan 22, 2006, at 9:56 AM, Trustin Lee wrote:
> > * SocketAddress is replaced with IoAddress (org.apache.common )
>
> What was wrong with using a SocketAddress?
>
> Of course, we could create this address scheme  
> (<providerType>:<transportType>:<address>) by extending  
> SocketAddress, but there was no point to do so because it only  
> causes downcasting.  As you know, you can't do anything with  
> SocketAddress.  You have to downcast it to something such as  
> InetSocketAddress or VmPipeAddress.

np, just curious :)

> Yes, this can be a problem, but we can make it non-singleton, of  
> course.  If we change so, there's no effective difference between  
> the old and the new from the viewpoint of the object composition.   
> It is just done by the IoService, not by you.

Having it not be a singleton would help. But I must admit that I  
prefer usage-specific interfaces. That is, code that acts as a client  
should only get an IoConnector, and should not have access to  
provider and service registration.

> Right.  Now they are gone.  This approach has a trade-off you  
> mentioned.  The advantage of user-defined attributes is that you  
> don't need to downcast and that it provides more flexibility.  For  
> example, let's assume that you need to switch to new AIO transport  
> type implementation.  All you need to do is change the providerType  
> to 'aio' from 'nio' in IoAddress.  With the old API, you'll have to  
> add more 'if ( session instanceof ... ) { ... setReceiveBufferSize 
> (...); }' sentences as you change the provider.  But with string  
> key, it works only if the providers used the same keys.
>
> Of course, this problem could be resolved if the authors of AIO  
> provider and NIO provider agreed on creating a common interface,  
> but I think it's too ideal.

I'm still against this change.. with the old API, there was a  
SocketIOSession that you had to cast to so you could modify socket- 
specific attributes. If there were shared things between AIO and NIO,  
then I think it could still be a SocketIOSession, since its still a  
socket, regardless of transport details. I also *REALLY* like the  
compile-time safety, and the ability to browse available options by  
looking at the interface.

> Please explain your complex integration scenario.  We'll make sure  
> it works with the new API.  :)

For testing, I start several instances of my server in a single JVM,  
each one having its own ServiceRegistry et al.  With the current  
setup, each instance is akin to a standalone instance. with IoService  
being a static, they would all share this same instance (unless I did  
some classloading trickery, which doing inside of JUnit wouldn't be  
fun), and the test environment would have another variable different  
from the production one.

Additionally, each server is really a client + a server. One thing I  
had done was share a ThreadPoolFilter between the client + server in  
the same JVM, but you have now done that with the new IoService.

The more difficult thing to fix would be that I have a IoConnector  
implementation that provides connection pooling on the client side.  
With IoConnector being the entry point for clients in the old API,  
this was very easy to do, I just gave my client code the new  
implementation. Now this would require a subclass of IoService to  
achieve the same thing.

Another thing on my TODO list was to create a ThreadPoolFilter that  
was backed by a Java5 ExecutorService, so I could further share  
thread pools in my application. By having that filter creation  
hardcoded into the IoService, doing this would be a bit more  
difficult. (My goal was to eventually have it so I could use Java5  
where-ever possible, including replacing Queue's and such that are  
now part of the JDK. Obviously this needs to be pluggable).

What I would change:

  * IoServiceProviderManager component instance (handles 'providers'  
Map)
  * DefaultFilterChainBuilder component  
(IoService.createFilterChainBuilder)
  * Connector (handles client connections, has a handle to  
IoServiceProviderManager and DefaultFilterChainBuilder instances)
  * ServiceManager (handles server-side stuff, has a handle to  
IoServiceProviderManager and DefaultFilterChainBuilder instances)
  * IoService has private instances of all the above, and wires them  
together. It is a singleton, and implements both Connector and  
ServiceManager, delegating calls to its private instances as  
appropriate. (You'd have to to IoService.getInstance().bind() in the  
simple usage mode)
  * Restore transport-type tweaking methods on the IoSession.

Thus, each bit is then pluggable, and one can completely ignore the  
IoService if desired. You can use the Connector and the  
ServiceManager to do client and server ops. And as long as each  
component takes the other components it needs in the constructor, I  
can drop them all in my picocontainer instance without worries :)

(I can do some refactorings and send a code snapshot if you like..)
-pete

-- 
proyal@apache.org - http://fotap.org/~osi



Mime
View raw message