Hi David,
first of all thanks for your feedback and suggestions!
Please see inline...
>
> 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
Integrate Notifier with Future looks interesting!
Currently in Grizzly 2.0 we have a possibility to pass a
CompletionHandler as parameter for I/O operation, so it's independent
of Future (like in AIO). Also grizzly IOFuture is still
java.util.concurrent.Future, not sure we'll want to separate them,
even if JDK Future API is not perfect.
But for sure never say never :))
> 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
Agree, API looks nice! However, as I told, for now I'd prefer to
support java.util.concurrent.Future. But it's just my opinion...
> Of course you could always port Grizzly to run on top of XNIO
> instead of NIO, and then you'd get it for free! ;-)
:))
Thank you!
WBR,
Alexey.
>
>
> - DML
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>