2006/1/23, peter royal <[EMAIL PROTECTED]>:
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.
Actually, IoService does what you think except that it's a singleton. It is like a ServiceRegistry. It creates acceptors and connectors for you and encapsulated them. Except that the number of acceptor/connector thread is one, everything is identical with the previous API. 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.
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.
Yes, right. If so, we could put a prefix such as 'provider.', but I'm not sure we need to do this in a unstable branch. Otherwise we could provide separate attribute getters and setters, but I don't know it's advantage to users.
Please explain your complex integration scenario. We'll make sure it works with the new API. :)
Thanks,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.
> * 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.
I don't like having this as a singleton with static methods. I need
to be able to have multiple instances in a single JVM, and this
breaks that. The new setup is a monolithic, which while great for new
users, makes it harder to tweak the behavior. The old setup was a
composition of multiple components, and I preferred that API style.
If the new IoService was merely a layer on top of the old API, I'd be
more in favor of that.
Actually, IoService does what you think except that it's a singleton. It is like a ServiceRegistry. It creates acceptors and connectors for you and encapsulated them. Except that the number of acceptor/connector thread is one, everything is identical with the previous API. 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.
> * No more transport-type specific property getters and setters.
> Now we use IoAddress properties and the user-defined attributes in
> IoSession. For example:
I liked the transport-specific getters and setters, since it provided
a level of type-safety when setting the properties, and you knew what
you were setting (there was javadoc on the methods, no chance of mis-
typing the attribute name, etc).
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.
Also, there are now 'magic' attribute name that affect the
operation of a session that can no longer be used as attribute names
in user code.
Yes, right. If so, we could put a prefix such as 'provider.', but I'm not sure we need to do this in a unstable branch. Otherwise we could provide separate attribute getters and setters, but I don't know it's advantage to users.
The changes look like they help simplify usage of MINA in simple
scenarios.. the examples are certainly much simpler, but for users
that might have a more complex integration, they seem to be somewhat
of a step backwards (my .02)
Please explain your complex integration scenario. We'll make sure it works with the new API. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
