On Feb 26, 2010, at 9:03 AM, Ashish wrote:
On Fri, Feb 26, 2010 at 7:03 PM, Emmanuel Lecharny <elecha...@gmail.com
> wrote:
Hi guys,
I'm reviewing the IoFuture interface and all the depending
interfaces and
classes. This is a complete mess. Looks like it has been built
layer after
layer, and I fell like being an archeoligist, diging to discover
what was
eating the previous civilization...
The ConnectFuture interface and its implementing classes
(DefaultConnectFuture and ConnectionRequest) is flawed in many ways.
First, it last as long as the session exists. To me, the semantic
of this
Future should be :
- create one when we start a connection
- once the connection has been accepted or refused (exception/
cancellation),
the Future is 'dead' (ie, won't be modified)
So there is need to store it into the Session's attributes as it's
currently done.
The ConnectionRequest class is a special sub-class used when an
immediate
(ie, blocking) connection wasn't possible. That's also a wrong
idea : if the
connection is granted immediately, because the connect() method is
blocking,
then the Future should be set to Done. Otherwise, it should be set
to done
once the session has been created. There is no need to use a
different
Future to manage this case, the blocking connection is just a
special case
of a non blocking connection.
There are many other areas in which Future are broken and need to be
cleaned, and I will post mails in the near future, but in any case,
it has
to be cleaned up.
I don't see how this can be fixed without unfreezing the API, btw...
Planning to invest more in 2.0? I thought we agreed to move on to
3.0 :)
Thoughts ?
Unless it breaks the system, i would say lets not loose our sleep
over this.
While I share the same opinion about the IoFuture hierarchy as you I
have the same sentiments as Ashish.
Regards,
Alan
