We need the http usecases pushed to the remoting project to as unit tests to move this forward. The first testcase should illustrate the required client poll. A second usecase should flesh out the desired behavior.
I agree the base remoting abstraction should be a bi-directional Client (currently is unidirectional), and it's then up to the specific transport to implement that bidirectionality how it wants, either by polling or connections from server to client or whatever.
Bottom line is this should be transparent to the user, which it currently isn't.
I've discussed the second issue with Tom (there is a remoting JIRA task for it already) and we want to get the messaging and remoting teams together so we can align some more and get to a common understanding of requirements etc.
This won't happen for a while, so for messaging 1.0.1 when the HTTP transport is due to be supported for JBoss Messaging we will have to work around this at our level.
Actually this isn't too hard (although not trivial) but definitely in the long term this should be handled by remoting.