"ovidiu.feodorov(a)jboss.com" wrote : In practical terms, we need to decide if is feasible to extend JBoss Remoting in a way that helps Messaging to reach its functionality and performance targets, or replace it with a specialized Messaging transport layer, independent of JBoss Remoting. | The latter should be a non-option. Remoting was created especially to be reused across JEMS so that there's a unified approach to "remoting". If it doesn't fit in the current requirements of JEMS projects it needs to be modified to do so. If this is not done, then I would question the whole point of the project. Now whether or not all the points you listed can be incorporated in Remoting in due time for Messaging's deliverables schedule is another question. If not then implement the features you need in quick and dirty fashion, and put down blocker task requests for all those features in the next release of Remoting. Whatever you do outside Remoting should be considered throw-away code (if not reusable inside Remoting). anonymous wrote : | Personally I think that adding the functionality we need (inside or outside of Remoting), instead of replacing Remoting altogether is the most efficient way to go forward. | In my opinion the only question should be where all the feature requirements you list are going to fit in Remoting's release schedule and write them down as JIRA tasks. Remoting filling those feature requests must be the final goal. If not in the current work-in-progress release, then the next one after that. My cents deposited. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978916#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...