CallAction interface design comments

[trumpetinc]

The CallAction interface defines a couple of enum values for unusual return types. I'm wondering what the purpose of these is?

I may be misunderstanding the design intent, but if a call doesn't want to return, I would imagine that it should throw an exception.

I am also thinking that execute() should throw Exception (instead of CallException). That way sub-classes don't have to do anything fancy with wrapping exceptions. i.e. handle the wrapping the framework instead.

[ghetolay]

It's explained on the javadoc comment :

Since Wamp allow null values on message if this methods return null a null value will be sent. To do not send any result message see Returns#NO_RETURN, and for empty message see Returns#EMPTY

That way we cover 4 kind of return :

• send "null" as a result => return null;
• send a empty result => return Returns.EMPTY
• send a CallError => throw CallException
• do not send any result => return Returns.NO_RETURN

The last one is not recommended and CompleteCallAction should be used instead.

Throw of CallException allow user to define the corresponding CallError message. We don't want to send Java specific error label.

[trumpetinc]

I'm not understanding why not sending a response to a remote procedure call would ever be a valid use-case.

I think that I understand EMPTY - that is required to support void return type, right?

Here's what I'm thinking (taking a cue from JAX-RS):

Perhaps the return value of CallAction should be constructed using a builder:

return CallResultBuilder.create().setResult(someObject).build();
or
return CallResultBuilder.create().setVoidReturn().build();
or
return CallResultBuilder.create().throwException(aThrowable).build();

If we do this, then CallAction doesn't need to have throws Exception in it's method signature.

For the annotation interface, we can certainly support thrown exceptions (translating them into the appropriate CallResult), but I don't think that needs to be done in CallAction.

I'm kind of thinking about things like this:

Lowest level - WebSockets traffic

Bare metal jWAMP - provide manually constructed end points, action handlers (CallAction, EventAction) - these wrap the low level WebSockets

Friendly jWAMP - use annotation scanning or builder interfaces to construct end points and action handlers - these wrap the bare metal jWAMP objects. It would also be possible to have non-annotation based objects at this layer that are friendlier to work with (i.e. something like CallAction that can return Object and/or throw exceptions).

I think that our design focus right now is on the Bare Metail jWAMP layer, so it is OK to expect users of that level of the API to return special values for exception handling, etc...

Am I on track with my thinking?