directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [mina] Introducing the New API for 0.9.1.
Date Sun, 22 Jan 2006 23:51:08 GMT
Hi Peter,

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.

> * 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.  :)

Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C

Mime
View raw message