custom authorization returns dictionary but not in kwargs?

[Dante Lorenso]

http://crossbar.io/docs/WAMP-CRA-Authentication/

  "The return value must be a dictionary with two mandatory attributes:

  secret: The secret shared with the client (possibly after salting)

  role: The authrole to assign the client to if successfully authenticated"

If we are returning a dictionary, why are we using [args] instead of using [kwargs]?

I'm having trouble understanding when to use kwargs and when to use args with an object as the first element of the args array.

Can I populate both args and kwargs when building WAMP messages or is it supposed to be just one or the other?

-- Dante

[David McCuskey]

tl;dr

when creating your own API, you can use either one or both. as you found, any dict can be passed as an item in args.

though in Python, the params in args are required, those in kwargs are optional. so taking your question with the Auth dict in args[0], i would look at that as implying "this info is required". (ie, you would never use defaults for the 'secret' and 'role' in Auth, so they're not in kwargs).

for simplicity, one could just use args for your API. OTOH, if your language doesn't like when args are missing, then kwargs can be used for optional items. to be future-proof, i would use both in the manner mentioned (i.e., required/optional args).

dmc

(i'm glad you brought this up, i was curious about it myself)

======

from reading the WAMP code, i imagine the idea of both options probably come from the named-parameter feature of Python (??) where items in args are things which are required and items in kwargs are not (because defaults can be defined by the function).

here's a example with three required args (obj,x,y) and two others which aren't because they are given defaults.

def info( obj, x, y, spacing=10, collapse=1 ):

Python can map args and kwargs to those params like so:

info( *msg.args, **msg.kwargs )

and the WAMP protocol will try a combo depending on what's coming back (from Autobahn Python):

res = types.CallResult(*msg.args)

res = types.CallResult(**msg.kwargs)

res = types.CallResult(*msg.args, **msg.kwargs)

unfortunately, dealing with these two sets of params with another language isn't as elegant.

here's test code from autobahnjs, note that both args/kwargs are in params though args isn't used in the function. (also note value for 'limit' is optional)

  function orders(args, kwargs) {

 test.log('orders()', args, kwargs);

 kwargs = kwargs || {};

 kwargs.limit = kwargs.limit || 5;

 return _orders.slice(0, kwargs.limit);

  }

in Python that would simply be:

def orders(limit=5):

as API dev, you could improve this in some code layer, but i think if kwargs/kwresults wasn't around then RPC, etc would feel more natural for all langs.

so a return from a server function:

return( obj, size )

could transparently map to this:

my_handler( obj, size )

that said, lang behavior will differ with missing args. i'm using Lua at the moment, and it's cool with just about anything. Python is not. so args/kwargs could be a decision to handle required/optional params across all langs, though actually dealing with them in individual langs might not be so elegant.

to improve the situation a little bit, in some code layer one could add kwargs to end of args and map to a function call. for example (reusing function from above):

Turning this:

function info( args, kwargs ):

into this:

function info( obj, x, y, kwargs ):

(again, success depends on lang and your code)

[Tobias Oberstein]

WAMP supports positional arguments (args) and keyword arguments (kwargs). WAMP also supports positional and keyword *return* values. All of the former is supported even when combined.

JavaScript only supports positional arguments and single value positional returns

Python supports positional and keyword arguments, but only single value, positional returns.

Oracle PL/SQL and PostgreSQL PL/pgSQL support all combinations - as WAMP.

WAMP was designed with a superset of all approach. We can expose any procedure in any language - naturally. The price is: possibly wrapping on the callee side if the calling language has less features.

The question why we use a single positional return with dict instead of a keyword based return is justified. We could have done the latter also.

The choice was made for reasons of convenience. Very few languages natively support anything but single positional returns.

I personally dont care much: we could have a community vote on this choice (and generally on use of this in WAMP meta procs in general)

Sent from Mobile (Google Nexus 5)

--
You received this message because you are subscribed to the Google Groups "Crossbar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.
To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/42918767-1004-4113-9ae0-26d02170d854%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.