Another thing to bear in mind with the proposed API. If you have a method write(byte[] byte), then when used with a non blocking implementation this method might return after having written only a partial number of the bytes. A similar reasoning applies to reads too. This is what non blocking is all about. A blocking implementation would block until all the bytes had been written. This preventing the thread neing used for anything else while the blocking is occurring. This means the semantics of the API differ depending on whether the actual implementation is blocking or non blocking. This also means it's going to be up to the application to piece together requests and responses. This is where most of the difficulty in a non blocking approach comes in. Trying to get the same API to cope with both approaches strikes me as somewhat analagous to the medieval alchemists trying to turn lead into gold. It seems to me that our biggest issue is getting an implementation up and running. So far we haven't even got the interface sorted. At the end of the day our end user won't give two hoots what our internal API looks like, but they will care that our performance sucks. As I've said before, I could probably knock something up in MINA in a few weeks. Considering we only have just over 4 weeks to have this fully implemented, I think this is our only feasible option. After that, we philosophise as much as we want about how to retrofit that in remoting. But please please let's not try and write a new non blocking framework - let's not go down the "Not invented here" path. There are already tried and tested frameworks out there. Let's get something working, and think about how this nicely fits into a new remoting api later when we have the luxury of time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980273#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...