If you're not familiar with the Remoting 3 API, none of this will make sense or it will not mean what you think. Fair warning given! :)

One-way requests need to move off of Client on to their own thing or be dropped. They don't fit on Client - which has type parameters for the request and reply type for one thing. What kind of single request listener would support both two-way and one-way requests? What if there's confusion between the client and server as to whether it's a one-way or two-way request? The client might end up just hanging there waiting for a response which will never come, or the server might try to send a response to a one-way request, which will result in an exception, and the operation will never succeed (the server would abort the operation, though the client would never directly discover this).

Yeah most of this stuff can be worked around. But I think it's a big red flag. There's a significant difference in semantics between one-way and two-way requests - the lightweight nature of one-way requests, relaxed delivery guarantees, the kinds of services invoked, etc. I think this merits its own division.

I'd rather see one of two things happen: (1) one-way message clients split off into their own interface, with a corresponding split in the various intermediate request transmission types, all the way up to the final RequestListener; or (2) one-way requests ditched altogether until a later version.

What do you think?