Tim wrote : | However I still believe we need very low level access for high performance operations. | For example, in the proposal, "raw" data is sent/received in byte[]s, but in the case that the implementation was using NIO this would mean copying to and from byte buffers which is going to be slow. | Not necessarily, the Remoting implementation can create ByteBuffers by wrapping the byte[] we send as an argument without copying anything, but I don't see any problem with using ByteBuffer instead of byte[] in the method signature. However, there's a little bit deeper problem here. I've just talked with Tom, his observation was that while he agrees with the necessity of making the distinction between synchronous and asynchronous calls at the API level, he doesn't necessarily want to expose access to the "low level" layers from the high level API. His argument is that top-level Remoting API should be kept as simple as possible, and some transports may simply not be able to honor the low level access exposed by the extAPI. Instead of exposing send(byte[]) (or send(ByteBuffer)) kind of methods, he is suggesting a chained marshaller mechanism instead, where we can plug-in our own low-level processing. It is not very clear to me how this would work and I need more details. He said that he's currently experimenting with it, and he needs a couple of days to reach a conclusion. He suggested a conference in two days from now, where we discuss his findings, and agree on the final version of http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensions. I think it's a good idea, we should decide on the final version of the document ASAP. Tom will let us know when he's done with his experimentation (hopefully not later than mid week). I will send everybody interested the conference details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980142#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...