Wrapping/unwrapping invocation results about autobahn-js

[aramallo]

@oberstet 😄 . I do like that!

[oberstet]

I don't think we have the right to allow sending single values in wamp messages as WAMP is pretty stable for a long time and there are plenty of implementations that rely on arguments as a list.

yep. the spec if pretty clear https://wamp-proto.org/wamp_bp_latest_ietf.html#name-result-2

But also we do not have anywhere in the SPEC description that 1-item wamp message arguments should be unwrapped before returning to client code.

yep. because that's up to an implementation to decide, and the spec only defines the wire protocol.

also note, that ABPy does exactly the same:

https://github.com/crossbario/autobahn-python/blob/f77396401d52a5284c3506171cf45eb64505804f/autobahn/wamp/protocol.py#L961

---

implementations can expose WAMP args/kwargs in different ways, as they see fit the host language and run-time environment.

you can say this is annoying (what is the canonical interface in host language X for WAMP?) or you can say this is welcome because there is no one best agreed canonical interface .. it depends. fwiw, I support the latter.

the reason why the question comes up anyways is:

• WAMP consequently supports both positional and keyword based parameters and return values.
• some host languages only support positional parameters and 1-positional return types
• some host languages only support positional and keyword parameters and 1-positional return types
• only very few host languages natively support all of it: positional and keyword for both parameters and return types

eg PL/SQL supports the full set, but sadly Python doesn't .. invalid syntax roughly like this:

def foo(x):
    if x > 0:
        return 2 * x, 3 * x, c = "x={}".format(x)
    elif x == 0:
        return 0, 23
    else:
        return 42, 5 * x, d = "hello world"

for i in [-1, 0, 1]:
    a, b, c: None, d: None = foo(i)
    print(a, b, c, d)

[oberstet]

just checked, I think the way ABPy works and exposes this stuff is "good" (the best we can do == the least surprising to the user):

from autobahn.wamp.types import CallResult

# returns both positional and keyword results filled from call arguments
def echo(*args, **kwargs):
    return CallResult(*args, **kwargs)

print(echo(2, 3, b = 4))

# returns a single positional result which is one list with all positional call arguments
def echo(*args):
    return args

print(echo(2, 3))

# returns zero or more positional results filled with positional call arguments
def echo(*args):
    return CallResult(*args)

print(echo(2, 3))

# same as 2nd!
def echo(*args):
    return CallResult(args)

print(echo(2, 3))

# returns zero or more keyword results filled with keyword call arguments
def echo(**kwargs):
    return CallResult(**kwargs)

print(echo(a=2, b=3))

# returns one positional result which is map with keyword call arguments
def echo(**kwargs):
    return kwargs

print(echo(a=2, b=3))

[aramallo]

My two cents, I agree with @oberstet that this might not be something the specification should prescribe, but I agree with @KSDaemon that it would be best for all clients to agree on a best practice.

The above ABPy code above exposes another issue, why isn't the RESULT.Details returned to the user in AB?

Same in AB|JS:

var Result = function (args, kwargs) {

   var self = this;

   self.args = args || [];
   self.kwargs = kwargs || {};
};

Another example in AB|JS:

var Event = function (publication,
                      topic,
                      publisher,
                      publisher_authid,
                      publisher_authrole,
                      retained,
                      forward_for) {

   var self = this;

   self.publication = publication;
   self.topic = topic;
   self.publisher = publisher;
   self.publisher_authid = publisher_authid;
   self.publisher_authrole = publisher_authrole;
   self.retained = retained;
   self.forward_for = forward_for;
};

In this case we are hardcoding the Publisher Identification fields, which means any other key in EVENT.Details will be ignored right? This limits extensibility (which brings me back to the _{custom_attr} discussion) but also means the we need to re-implement client code when the WAMP Spec itself blesses a new attribute.

If it was for me I would always make the client return a RESULT which includes args, kwargs and details respecting the best practices for the host language. .e.g object | tuple | struct containing those keys when only single return value is allowed.

[KSDaemon]

Yeah! Lack of details in call results is an important issue.
In Wampy.js for example, in all cases (event, result) I return all of them:

{
         details
         argsList
         argsDict
}

[oberstet]

The above ABPy code above exposes another issue, why isn't the RESULT.Details returned to the user in AB?

you can, just enable it using RegisterOptions and SubscribeOptions

https://github.com/crossbario/autobahn-python/blob/f77396401d52a5284c3506171cf45eb64505804f/autobahn/wamp/types.py#L809 - there are 2 flavors (just enable will use "details" as keyword arg, and correctly pop off details before forwarding kwargs - or you can specify the name for details, so that it doesn't collide with your own details in kwargs)

[oberstet]

@aramallo

The above ABPy code above exposes another issue, why isn't the RESULT.Details returned to the user in AB?

in ABPy, this is already implemented:

https://github.com/crossbario/autobahn-python/blob/f77396401d52a5284c3506171cf45eb64505804f/autobahn/wamp/protocol.py#L943

in ABJS: because nobody asked until now;) seriously, you are right. we could add that (as it is for registering procedures or event handlers):

1. add a client-side option to enable

autobahn-js/packages/autobahn/lib/session.js

Line 1205 in 562974e

Session.prototype.call = function (procedure, args, kwargs, options) {

2. and if enabled, always return a complex result with details filled in

autobahn-js/packages/autobahn/lib/session.js

Line 683 in 562974e

// maybe wrap complex result:

when enabling, it must always return a complex result, even if the RESULT has only 1 positional result (because JS only allow 1 result in functions)