Re: [mina] Introducing the New API for 0.9.1.

[peter royal]

On Jan 22, 2006, at 6:51 PM, Trustin Lee wrote: 2006/1/23, peter royal <[EMAIL PROTECTED]>: 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 --  [EMAIL PROTECTED] - http://fotap.org/~osi

smime.p7s
Description: S/MIME cryptographic signature