On 12/16/2008 10:37 AM, Jeanfrancois Arcand wrote:
> Salut,
>
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> I would like to propose a change to the current Grizzly 2.0 way of
>> using Future. Instead of having:
>>
>> IOFuture
>> ConnectFuture
>> ReadFuture
>> WriteFuture
>>
>> I would like to align with the API and remove the above classes and
>> instead add something like GrizzlyFuture. Looking at the code, the
>> specialized API added to the above classes can be replaced with
>
> I must have said that GrizzlyFuture is out implementation of the Future
> interface and not exposed to the users/framework.
Might I suggest that you have a look at my IoFuture<T> interface which I
use in XNIO:
http://docs.jboss.org/xnio/1.1.1.GA/api/org/jboss/xnio/IoFuture.html
http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org/jboss/xnio/IoFuture.java
and the abstract implementation:
http://docs.jboss.org/xnio/1.1.1.GA/api/org/jboss/xnio/AbstractIoFuture.html
http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org/jboss/xnio/AbstractIoFuture.java
and finally a couple of other useful links:
http://docs.jboss.org/xnio/1.1.1.GA/api/org/jboss/xnio/FailedIoFuture.html
http://docs.jboss.org/xnio/1.1.1.GA/api/org/jboss/xnio/FinishedIoFuture.html
http://docs.jboss.org/xnio/1.1.1.GA/api/org/jboss/xnio/IoUtils.html#getFuture(org.jboss.xnio.IoFuture)
I've found this API (which I developed as a result of my experiences with
java.util.concurrent as well as MINA Future APIs, and community feedback)
to be easy to use from both a user and implementer's standpoint. The key
features are:
- Using an enum to represent the current status, allowing for things like
"switch (future.await())" and other handy patterns
- The ability to register any number of async notifiers, along with the use
of a simple Notifier interface and an abstract implementation of that
interface to allow two different coding styles for handling asynchronous events
- The ability to create a java.util.concurrent.Future wrapper for IoFuture
- The ability to async-cancel any operation on a best-effort basis (with
well-defined semantics)
- It is suitable for usage for any future I/O operation I could think of,
ranging from simple I/O operations like reading and writing to connection
establishment, and I even use it in JBoss Remoting for getting network
invocation results
Of course you could always port Grizzly to run on top of XNIO instead of
NIO, and then you'd get it for free! ;-)
- DML