Last Will/Testament for WAMP sessions/transports

[hawkowl]

See https://github.com/crossbario/crossbar/issues/886 for discussion.

From @oberstet :

If we'd use the WAMP/CB meta API, we could have:

wamp.session.publish_testament(<topic>, <args>, <kwargs>, <publish_options>, <scope: "transport" | "session")
wamp.session.flush_testament(<scope: "transport" | "session">)

Which would allow submitting multiple last wills (that later would be published as originally submitted), and to flush (remove) any previously submitted last wills.

[oberstet]

@hawkowl For me, this pretty much covers exactly the useful feature scope and the text is precise with lots of examples. I'd go ahead on this one and implement it as describe in your PR in Crossbar.io - but leave the spec PR still open.

[hawkowl]

@oberstet sounds good to me, will do

[Jopie64]

I think it would also be nice to remove specific testaments. On my company we use WAMP to transfer object instance state between applications e.g. like this:

• Caller calls RPC objectA.create
• Callee creates instance 1 of type objectA and returns instance ID (1)
• Callee registers some procedures for this instance like objectA.ID1.dowork
• Caller subscribes to some instance specific topics like objectA.ID1.statechange
• The caller and callee also subscribe to the objectA.ID1.end topic.

When one of the nodes is done with objectA instance 1, the object is destroyed and the objectA.ID1.end topic is signalled. This way the other node can free up resources and unregister/unsubscribe instance specific topics/procedures too.

But when one of the nodes disconnects for some reason there's of course no way for them to signal their destroyed instances and other nodes will keep using them. For this the testament feature would come in handy.

However, when testament objectA.ID1.end is added, it would be useful to be able to flush only this testament when instance ID 1 is destroyed, and leave the other object instances of the same node intact. Otherwise testaments would pile up quickly in some scenarios.

Therefore I propose the following:

• wamp.session.add_testament returns a testament ID
• wamp.session.flush_testament accepts an ID to flush only that testament.
• flush_testament has another argument that tells it to publish its event or just remove it. Or this is a separate procedure like drop_testament or something.

Is this reasonable? Or did I miss something?

[oberstet]

@Jopie64 What you sketch is certainly reasonable - it indeed allows to cover more use case, is more flexible, and fits into the bigger picture. So I'd be +1 on this ..