New releases: Crossbar.io, AutobahnPython and AutobahnJS

#1

Hi all,

we're excited to release new versions of

- Crossbar.io 0.10.2
- AutobahnPython 0.10.1
- AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don't hesitate: we'd love to hear about!

Cheers,
/Tobias

NEW Features

···

============

1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

2. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

3. Shared Registrations

With this, multiple components (or instances of a component) can register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions that registered a matching procedure, and the dispatching will be based on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random. These allow you to scale-out your application components or configure hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

4. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/
http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#2

Hi,

Having upgraded fro V9 I find that my application no longer works … “RegisterOptions” it seems no longer supports “discloseCallerTransport” or “discloseCaller” …

Any chance you could point me at the replacement functionality ?

···

On Sunday, 1 March 2015 19:39:44 UTC, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#3

Ok, after much reading and tearing of hair I’ve answered my own question. Rather than keying off authid
(which is what I was doing) I’ve re-coded to store the authid against the sessionid in the router’s authentication

override, then I’m using a db lookup / session cache to resolve the session id back to the authid.

I can see ‘why’ this was changed … massive impact on pre-existing code tho’ … one further point I couldn’t

quite see, is there an easy way to make call’s default to {disclose_me:true} or am I stuck with including it

in each call ?

···

On Monday, 9 March 2015 09:56:12 UTC, Gareth Bult wrote:

Hi,

Having upgraded fro V9 I find that my application no longer works … “RegisterOptions” it seems no longer supports “discloseCallerTransport” or “discloseCaller” …

Any chance you could point me at the replacement functionality ?

On Sunday, 1 March 2015 19:39:44 UTC, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#4

Hi Gareth,

Ok, after much reading and tearing of hair I've answered my own
question. Rather than keying off authid

Sorry recent changes have caused you issues - FWIW, the old scheme had 2 flaws:

- each and every call carries all the lengthy details of the caller maybe even caller transport details
- it made disclosure a decision of the receiver, not the sender (or router) who should decide about this

In calls/events, if the sender is disclosed, this is done by including the session ID and only that.

A component interested in caller/publisher details including transport level information can use the meta API of Crossbar.io

http://crossbar.io/docs/Session-Metaevents-and-Procedures/
http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

(which is what I was doing) I've re-coded to store the authid against
the sessionid in the router's authentication
override, then I'm using a db lookup / session cache to resolve the
session id back to the authid.

I can see 'why' this was changed .. massive impact on pre-existing code
tho' ... one further point I couldn't
quite see, is there an easy way to make call's default to
{disclose_me:true} or am I stuck with including it
in each call ?

Yeah, that gets old quickly. Alex has just implemented a global option in AutobahnJS which allows to set disclosure related flags:

https://github.com/tavendo/AutobahnJS/blob/master/package/test/test_rpc_caller_disclose_me.js#L154

Will be in the upcoming AutobahnJS release!

Cheers,
/Tobias

···

Am 09.03.2015 um 19:59 schrieb Gareth Bult:

On Monday, 9 March 2015 09:56:12 UTC, Gareth Bult wrote:

    Hi,

    Having upgraded fro V9 I find that my application no longer works ..
    "RegisterOptions" it seems no longer supports
    "discloseCallerTransport" or "discloseCaller" ..

    Any chance you could point me at the replacement functionality ?

    On Sunday, 1 March 2015 19:39:44 UTC, Tobias Oberstein wrote:

        Hi all,

        we're excited to release new versions of

        - Crossbar.io 0.10.2
        - AutobahnPython 0.10.1
        - AutobahnJS 0.9.6

        with major updates and new features! See below.

        If you have feedback, issues or opinions, please don't hesitate:
        we'd
        love to hear about!

        Cheers,
        /Tobias

        NEW Features
        ============

        1. Pattern-based Subscriptions

        Using this, you can subscribe to a pattern of URIs and you will
        then
        receive events matching the pattern.

        Patterns can be prefix-based and wildcard-based. Please see the
        introduction here

        http://crossbar.io/docs/Pattern-Based-Subscriptions/
        <http://crossbar.io/docs/Pattern-Based-Subscriptions/>

        and the complete example

        https://github.com/crossbario/crossbarexamples/tree/master/patternsubs
        <https://github.com/crossbario/crossbarexamples/tree/master/patternsubs>

        2. Pattern-based Registrations

        Using this, you can register a procedure on a pattern of URIs
        and your
        procedure will then be called for calls matching the pattern.

        Patterns can be prefix-based and wildcard-based. Please see the
        introduction here

        http://crossbar.io/docs/Pattern-Based-Registrations/
        <http://crossbar.io/docs/Pattern-Based-Registrations/>

        and the complete example

        https://github.com/crossbario/crossbarexamples/tree/master/patternregs
        <https://github.com/crossbario/crossbarexamples/tree/master/patternregs>

        3. Shared Registrations

        With this, multiple components (or instances of a component) can
        register a procedure under the same URI specifying a invocation
        policy.

        When a call comes in, the call will be dispatched to one of the
        sessions
        that registered a matching procedure, and the dispatching will
        be based
        on the invocation policy.

        Invocation policies include: single, first, last, roundrobin and
        random.
        These allow you to scale-out your application components or
        configure
        hot-standby and fail-over strategies.

        Please see the introduction here

        http://crossbar.io/docs/Shared-Registrations/
        <http://crossbar.io/docs/Shared-Registrations/>

        and the complete example

        https://github.com/crossbario/crossbarexamples/tree/master/sharedregs
        <https://github.com/crossbario/crossbarexamples/tree/master/sharedregs>

        4. WAMP Meta Prodedures and Events

        Crossbar.io now implements a whole bunch of WAMP meta procedures
        and topics.

        Please see here for introductions

        http://crossbar.io/docs/Session-Metaevents-and-Procedures/
        <http://crossbar.io/docs/Session-Metaevents-and-Procedures/>
        http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/
        <http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/>
        http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/
        <http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/>

        and here for the complete example

        https://github.com/crossbario/crossbarexamples/tree/master/metaapi
        <https://github.com/crossbario/crossbarexamples/tree/master/metaapi>

        ===

--
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
<mailto:crossbario+...@googlegroups.com>.
To post to this group, send email to cross...@googlegroups.com
<mailto:cross...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/crossbario/2e35d266-1989-49a1-a99e-74290358c604%40googlegroups.com
<https://groups.google.com/d/msgid/crossbario/2e35d266-1989-49a1-a99e-74290358c604%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

Hi Ralph!

As far as I’m aware the only problem with backward compatibility is that the “disclose_caller” option no longer exists for registrations. For the reasons Tobias gives above, this is now under the control of the caller (which can set “disclose_me” on the call).

Regards,

Alex

···

Am Sonntag, 15. März 2015 02:02:15 UTC+1 schrieb ralph stone:

what do we need to know about backward compatibility?

On Monday, 2 March 2015 06:39:44 UTC+11, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#6

We find this to be a horrible breakage also.

Upon connecting to Crossbar, we will authenticate front-end users with a username and password. That means we send authid to crossbar as the ‘username’ of the connecting user. Inside authenticate, we look up this username and convert it to account_id (return authid = account_id). We want crossbar to hence forth store and pass the ‘account_id’ value to all RPC calls. The account_id is what we need to see for all front-end users with every RPC call that is made. Instead, now, crossbar is sending only some session id. We are now forced to look up the session_id to account_id mapping for every call.

Crossbar already did the session_id-to-account_id map lookup on authentication, so why are we being forced to store this mapping in another layer of the system and have to watch wamp.session.on_leave and on_join events to maintain this mapping? The mapping should be kept inside crossbar and the backend unique account_id should be passed to every backend RPC call automatically, IMHO.

I think Gareth and I have a common usage scenario here. We want to avoid making developers build more infrastructure than they should have to.

The proposal should be as follows:

  • crossbar configuration (config.json) can define that all rpc calls will disclose the caller

  • crossbar stores authid for connected sessions (session id mapped to authid)

  • authid can be changed to a true back-end unique identifier during authentication (authentication authid IN = username, authentication authid OUT = account_id)

  • authid is passed to all RPC calls when disclosure is turned on

With these changes, Crossbar manages the session to account_id lookup table and all backend calls will receive authid disclosure without concern about whether front-end callers remembered to turn on the feature.

– Dante

···

On Monday, March 9, 2015 at 1:59:44 PM UTC-5, Gareth Bult wrote:

Ok, after much reading and tearing of hair I’ve answered my own question. Rather than keying off authid
(which is what I was doing) I’ve re-coded to store the authid against the sessionid in the router’s authentication

override, then I’m using a db lookup / session cache to resolve the session id back to the authid.

I can see ‘why’ this was changed … massive impact on pre-existing code tho’ … one further point I couldn’t

quite see, is there an easy way to make call’s default to {disclose_me:true} or am I stuck with including it

in each call ?

On Monday, 9 March 2015 09:56:12 UTC, Gareth Bult wrote:

Hi,

Having upgraded fro V9 I find that my application no longer works … “RegisterOptions” it seems no longer supports “discloseCallerTransport” or “discloseCaller” …

Any chance you could point me at the replacement functionality ?

On Sunday, 1 March 2015 19:39:44 UTC, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#7

Hi Dante,

crossbar configuration (config.json) can define that all rpc calls will disclose the caller

Agreed, should be possible: https://github.com/crossbario/crossbar/issues/283

crossbar stores authid for connected sessions (session id mapped to authid)

This is how it works already. Crossbar.io stores all auth (and transport) level info internally.

authid can be changed to a true back-end unique identifier during authentication (authentication authid IN = username, authentication authid OUT = account_id)

Already implemented. Please see http://crossbar.io/docs/WAMP-CRA-Authentication/ => Dynamic Auth. => authid: The authentication ID which will be assigned to the client

authid is passed to all RPC calls when disclosure is turned on

This is where I disagree. The authid is just one info of potential interest. Another developer asked for transport level info (like Cookies from WebSocket handshake).

It doesn’t make sense to forward this bulky info on each and every call forwarded.

Instead, you can retrieve it when needed by calling "wamp.session.get" ... you might cache it yourself, or you might just call “wamp.session.get” each time you need it.

Cheers,
/Tobias

···

Am Mittwoch, 25. März 2015 16:59:32 UTC+1 schrieb Dante Lorenso:

We find this to be a horrible breakage also.

Upon connecting to Crossbar, we will authenticate front-end users with a username and password. That means we send authid to crossbar as the ‘username’ of the connecting user. Inside authenticate, we look up this username and convert it to account_id (return authid = account_id). We want crossbar to hence forth store and pass the ‘account_id’ value to all RPC calls. The account_id is what we need to see for all front-end users with every RPC call that is made. Instead, now, crossbar is sending only some session id. We are now forced to look up the session_id to account_id mapping for every call.

Crossbar already did the session_id-to-account_id map lookup on authentication, so why are we being forced to store this mapping in another layer of the system and have to watch wamp.session.on_leave and on_join events to maintain this mapping? The mapping should be kept inside crossbar and the backend unique account_id should be passed to every backend RPC call automatically, IMHO.

I think Gareth and I have a common usage scenario here. We want to avoid making developers build more infrastructure than they should have to.

The proposal should be as follows:

  • crossbar configuration (config.json) can define that all rpc calls will disclose the caller
  • crossbar stores authid for connected sessions (session id mapped to authid)
  • authid can be changed to a true back-end unique identifier during authentication (authentication authid IN = username, authentication authid OUT = account_id)
  • authid is passed to all RPC calls when disclosure is turned on

With these changes, Crossbar manages the session to account_id lookup table and all backend calls will receive authid disclosure without concern about whether front-end callers remembered to turn on the feature.

– Dante

On Monday, March 9, 2015 at 1:59:44 PM UTC-5, Gareth Bult wrote:

Ok, after much reading and tearing of hair I’ve answered my own question. Rather than keying off authid
(which is what I was doing) I’ve re-coded to store the authid against the sessionid in the router’s authentication

override, then I’m using a db lookup / session cache to resolve the session id back to the authid.

I can see ‘why’ this was changed … massive impact on pre-existing code tho’ … one further point I couldn’t

quite see, is there an easy way to make call’s default to {disclose_me:true} or am I stuck with including it

in each call ?

On Monday, 9 March 2015 09:56:12 UTC, Gareth Bult wrote:

Hi,

Having upgraded fro V9 I find that my application no longer works … “RegisterOptions” it seems no longer supports “discloseCallerTransport” or “discloseCaller” …

Any chance you could point me at the replacement functionality ?

On Sunday, 1 March 2015 19:39:44 UTC, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#8

Right now, you are sending a 'caller' detail which is the session_id of the WAMP connection. What good is this data to me? ... I want the unique Id of my caller instead. I see the unique id of my connected client as another RPC parameter. For example, myfunc(a, b, c)

   com.example.myfunc ( [ a, b, c, ] )

And Ideally, account_id ("authid") would be in this list of parameters also:

   com.example.myfunc ( [ a, b, c, authid ] )

We can't trust the data to come from the client, but we can trust it to come from Crossbar since Crossbar stores the data after authentication. So, let's have crossbar pass that info in the details:

   com.example.myfunc ( [ a, b, c ], {}, { authid: ... } )

But what you are telling me is that there is much information that would be in details, so you want to remove it all and instead send a reference ID that can be used to look up the data later using wamp.session.get!

   com.example.myfunc ( [a, b, c], {}, { caller: ... } )

But, now I have to write this code at the top of all of my RPC calls:

   account_id = call_wamp_session_get_to_find_authid(callerid);

So, there's a round-trip sub-request to look up the data that you didn't want to send in the first place! How is that *more* efficient? I understand that I can cache that lookup in my back-end caller, but what will that cache look like?

   caller "session_id" ---> authid

Does that look familiar? It should, because you *already* have that map inside Crossbar itself! Why are we duplicating effort here?

What I'm complaining about is that WAMP clients are being forced to write a layer of code we didn't have to write before. This is a task that can easily be (and is already being) handled by Crossbar itself.

How about Crossbar adds a configuration value into config.json that allows us to choose which "details" info are forcefully passed to all back-end clients? Perhaps an array of names?

   "realms" : [ {
   ...
     "roles" : [ {
       "id" : "backend",
       "name" : "backend",
       "permissions" : [ {
         "uri" : "*",
         "publish" : true,
         "subscribe" : true,
         "call" : true,
         "register" : true
       } ],
       "force-details" : [ "authid", ... ]
     },

By doing this, Crossbar only needs to send a small piece of data (authid is an integer for me), and can save a lot of work having to look up and cache this information. Crossbar already has the map, why force another round-trip call to wamp.session.get when we *know* that call needs to happen every time anyhow.

With an implementation like "force-details", you also solve the problem that requires all callers to request 'disclose_me' : true on every call (isn't that also a waste of payload?). Now, backend role can request the 'authid' id for each and every RPC request. Clients don't have to add the disclose me request, and backend WAMP clients don't have to maintain a caller to account id cache or lookup function.

-- Dante

···

On 3/30/15 9:18 AM, Tobias Oberstein wrote:

> authid is passed to all RPC calls when disclosure is turned on

This is where I disagree. The authid is just one info of potential
interest. Another developer asked for transport level info (like Cookies
from WebSocket handshake).

It doesn't make sense to forward this bulky info on _each and every_
call forwarded.

Instead, you can retrieve it when needed by calling "|wamp.session.get"
...| you might cache it yourself, or you might just call
"wamp.session.get" each time you need it.

0 Likes

#9

Hi Tobias,

Cool features!

I have a suggestion though, maybe the topics of wamp.subscription.on_subscribe/wamp.subscription.on_unsubscribe can have a subscription id, like wamp.subscription.on_subscribe.1099266751 and wamp.subscription.on_unsubscribe.1099266751, and something similar for registrations.

This allows to subscribe only to events of a specific subscription. Of course you can subscribe to all subscriptions using match = prefix.

Elad

בתאריך יום ראשון, 1 במרץ 2015 בשעה 21:39:44 UTC+2, מאת Tobias Oberstein:

···

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes

#10

what do we need to know about backward compatibility?

···

On Monday, 2 March 2015 06:39:44 UTC+11, Tobias Oberstein wrote:

Hi all,

we’re excited to release new versions of

  • Crossbar.io 0.10.2

  • AutobahnPython 0.10.1

  • AutobahnJS 0.9.6

with major updates and new features! See below.

If you have feedback, issues or opinions, please don’t hesitate: we’d
love to hear about!

Cheers,

/Tobias

NEW Features

============

  1. Pattern-based Subscriptions

Using this, you can subscribe to a pattern of URIs and you will then
receive events matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Subscriptions/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternsubs

  1. Pattern-based Registrations

Using this, you can register a procedure on a pattern of URIs and your
procedure will then be called for calls matching the pattern.

Patterns can be prefix-based and wildcard-based. Please see the
introduction here

http://crossbar.io/docs/Pattern-Based-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/patternregs

  1. Shared Registrations

With this, multiple components (or instances of a component) can
register a procedure under the same URI specifying a invocation policy.

When a call comes in, the call will be dispatched to one of the sessions
that registered a matching procedure, and the dispatching will be based
on the invocation policy.

Invocation policies include: single, first, last, roundrobin and random.
These allow you to scale-out your application components or configure
hot-standby and fail-over strategies.

Please see the introduction here

http://crossbar.io/docs/Shared-Registrations/

and the complete example

https://github.com/crossbario/crossbarexamples/tree/master/sharedregs

  1. WAMP Meta Prodedures and Events

Crossbar.io now implements a whole bunch of WAMP meta procedures and topics.

Please see here for introductions

http://crossbar.io/docs/Session-Metaevents-and-Procedures/

http://crossbar.io/docs/Subscription-Meta-Events-and-Procedures/

http://crossbar.io/docs/Registration-Meta-Events-and-Procedures/

and here for the complete example

https://github.com/crossbario/crossbarexamples/tree/master/metaapi

===

0 Likes