Allow implementation specific attributes in details/options about wamp-proto HOT 19 CLOSED

Dealers and Brokers MUST forward x_... attributes in CALL.Options and PUBLISH.Options messages to INVOCATION.Details and EVENT.Details messages.

Should we allow x_... attributes in messages directed to Dealers and Brokers (like SUBSCRIBE and REGISTER) at all?

from wamp-proto.

We should (at least in SUBSCRIBE):
As I mentioned, this allows custom pub/sub subscriptions, such as subscribing to all events of a given topic, which match a given criteria (for example, all the sales that their sum is at least 100$ or have at least 10 products)

from wamp-proto.

"All sales with sum 100$ and at least 10 products": This is application specific behavior, and a generic broker won't be able to dispatch those, since it lacks the application code for that. See also: #32

Applications can use generic topics and eligible or can use ephemeral topics to manage very specific scenarios like above.

from wamp-proto.

What I meant is a scenario where subscribers are interested only in part of the data. For example, one subscriber wants to get "All sales with sum 100$ and at least 10 products", and another one wants "All sales with sum less than 10$ and or not more than 5 products".
A new subscriber may want to subscribe to events matching a different criteria, making the topics dynamic. The subscribers can pass their criteria via the topicUri parameter, and a publisher can parse it, but this is abuse of the topicUri. An options parameter passed to subscribe can solve this issue more elegantly.

The problem that occurs is that if the broker is generic, it really won't be able to filter only the requested events. This can be solved if the publishers get notified (for example, via metaevents) about subscriptions' options. This way, a publisher will be able to send to a subscriber only the data it is interested in. This complicates the publisher (it would have to compute the events to send per subscriber, and use eligible), but achieves the target.

from wamp-proto.

Publishers don't get events (neither "normal" nor "meta"). Publishers don't know anything about Subscribers. This is the essence of Publish & Subscribe: decoupling of Publishers and Subscribers via Topics.

There seems to be (at least) 3 approaches to what you want:

1. Implement a Broker that runs application code for event routing
2. Do Content-based PubSub instead of Topic-based
3. Implement custom routing logic in a Callee or Subscriber

Regarding 3., this is certainly possible with WAMP.

There are currently no plans to specify/support 2. with WAMP. To a certain extent, similar results can be achieved with pattern-based subscriptions.

With 1., this is clearly a non-goal, since having application specific routing logic pretty much makes the whole WAMP endeavour moot.

from wamp-proto.

A couple of points:

I think its impossible that publishers know nothing about subscribers - there is an option to specify in a publication the eligible/excluded session ids of some publishers, so I guess the publishers do know what ids they specify there (I guessed the approach would be METAEVENTS, maybe I was wrong)

I understand that your goal in WAMPv2 is that the servers are only brokers that route messages between publishers and subscribers (or callers and callees).
I think it's a shame, I think that for most of the sceanarios, a classic client/server will do the job (such as in WAMPv1). It is ok to allow brokers via the spec, but I don't think that implementations should be forced to be brokers (For most sceanarios it doesn't have any advantage, it only makes things more complicated).

Anyway, can you give more details about your solution for my requirement? Do you intend that clients should subscribe to all events and filter only the events they are interested in? Because I'm not happy with this one.

from wamp-proto.

Regarding exclude/eligible: you are right, in this respect publishers do potentially know something (WAMP session IDs) about other WAMP peers. However, they still don't know if those are actually subscribed or not. Nor if those session exist at all. And exclude/eligible is already more than a usual Publish & Subscribe system allows.

WAMPv2 is a superset of WAMPv1 featurewise. Also, the "server" for WAMPv1 was always a Broker anyway. The only real difference is that with WAMPv1 the "server" was the only place to implement the Callee role, while with WAMPv2 this is still 1 option, but you also can have a "client" as Callee. So nothing is taken away (other than HTTP URIs, but this isn't relevant in this context I guess).

So I am wondering: did you use WAMPv1? And if so, how does your app work today, and what do you fear would not work with WAMPv2?

from wamp-proto.

Regarding options to implement complex, application specific filtering conditions:

Option 1:

Have a Callee endpoint com.paroga.setnotify where you can provide any search/filter conditions you like in CALL.Args
Subscribers (after calling com.paroga.setnotify) then subscribe to the "generic" topic com.paroga.onnotify
But your backend (the Publisher) can restrict publications using PUBLISH.Options.eligible to the exact set of desired recipients determined based on the search/filter conditions originally supplied to com.parago.setnotify

The Callee behind "com.paroga.setnotify" would need to identify the session ID of the Caller to manage the receivers. This is missing (we only have it for PubSub), but is natural to add: #31

Option 2:
Another approach would be to use "ephemeral topics": com.paroga.setnotify might return an ephemeral topic URI to the Caller based on the specific search/filter conditions requested: com.paroga.onnotify.e124.

The backend can publish to the ephemeral topic com.paroga.onnotify.e124 based on any specific filter conditions.

Two Callers wishing to get notified based on the same set of search/filter conditions would get handed out the same ephemeral topic.

from wamp-proto.

Option 3:

Say you want content-based subscriptions on a set of attribute_i = value_i conditions where 1 <= i <= n.

When publishing an event, publish to a topic structured like this:

com.paroga.complexevent.<value for attribute 1>.<value for attribute 2>. ... . <value for attribute n>

When subscribing, subscribe using wildcard patterns, e.g.

com.paroga.complexevent.small-basket.high-value..

from wamp-proto.

Ok, thanks for the answers.
Today I have some WAMPv1 based applications, which all are classic client/server applications: i.e: clients subscribe to topics which the server publishes events to, and client call server methods. In my current applications clients don't publish events, they only subscribe to topics and call procedures.

If the server can still have a role of an application with logic, I guess I have no problems, but I understand from your previous comment and from #32 that the "server" will now be a broker and can't have specific application logic.

I'll reply about the suggestions in separate comments.

from wamp-proto.

Option 1:
I guess it works, but I find it ugly from the following reasons:
*It makes the SUBSCRIBE message non-atomic
*It makes the role of pub/sub messages in protocol unclear - in the same fashion all pub/sub mechanism could have been predefined endpoints which the client calls via the rpc messages (for example, a method for "subscribe", a method for "unsubscribe", a method for "publish" and etc)

from wamp-proto.

You can have a "server" that implements the roles: Callee, Publisher, Dealer and Broker, and a "client" that implements Subscriber and Caller.

You cannot have a server that implements Publisher-only talking directly to a client implementing Subscriber. This isn't PubSub, but direct messaging. And you don't need WAMP for that. Just use plain WebSocket.

If your existing server internally published messages to some topic, but the event was only received on 1 client, despite more than 1 client being subscribed to the topic published to, your server in fact never acted as a WAMPv1 compliant Broker. If, on the other hand, your server does dispatch to all subscribed clients, then it acts as a Broker already today. And any application code running aside this Broker just acts as an "internal" Publisher.

With WAMPv1, the AutobahnPython implementation always acted as a full Broker: events published (be it from some client, or from application logic running aside the Broker) always got dispatched according to PubSub.

from wamp-proto.

Of course the event was published to all topic subscribed clients, and not only to a specific subscribed client.

from wamp-proto.

Option 2:
I don't understand how does the client specify the filter it is interested in.

Option 3:
Not very flexible in the following senses:
*Allows only specific scenarios (Only events that agree on specific attributes - it is unclear how to request a range, or a "OR" between the attributes)
*Other criterias can be encoded in the topic uri, but this is abuse of the topic uri.

from wamp-proto.

How does a client subscribe to a complex filter based subscription ("all orders > 100$ with number of products <= 5") in your existing application? Or as a corollary: how do you determine to which clients you dispatch an event based on such complex conditions?

Regarding option 2:

A client calls com.paroga.setnotify and provides the filter conditions ("all orders > 100$ with number of products <= 5") as call arguments. The call returns with call result com.paroga.onnotify.e124. The client then subscribes to com.paroga.onnotify.e124. The Callee implementation for the former will need to remember the filter conditions that apply to the ephemeral topic com.paroga.onnotify.e124.

When an order is placed, application code will need to determine all ephemeral topics associated with filter conditions that match the order placed. And then application code published to those determined topics.

Regardin option 3: I agree. It is a limited form of content-based PubSub, misusing topics and pattern-based subscriptions to simulate dynamic filtering.

The problem with content-based PubSub is basically: Any "rules" language (other than a full blow programming language) will never be enough to cover all scenarios. What if the filter conditions depends not only on the event at hand, but context ("orders larger than the average of last 24h average")? And so on. I don't see how this can be done generically.

from wamp-proto.

My current applications abuse the topicUri: the filter is encoded in the topicUri. When a client subscribes, my applications parses the topic uri and subscribes the topic (if not already subscribed) to an inner handler with the parsed crietria. All events the application dispatch are published through the inner handler that dispatches only events that are relevant for each topic.

from wamp-proto.

Alright. I see. Essentially, what you have is an application specific Broker. The Broker runs application specific event routing code. And now I understand why you want custom data for SUBSCRIBE. That would allow you to get rid of the Topic/URI encoding hack. Fair enough.

I think it is honest to acknowledge that this directly collides with #32

I am ready to discuss this (if you like / are motivated). Probably then better on #32, since this issue here is in a way a consequence of the former.

from wamp-proto.

Extensibility
New message types
Implementation specific attributes in Details and Options

from wamp-proto.

WAMP allows implementation specific attributes with the prefix _.

from wamp-proto.