On Fri, Feb 26, 2010 at 7:03 PM, Emmanuel Lecharny <[email protected]> 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. thanks ashish
