Re: [hybi] Subscription/topic confusion

Tobias Oberstein <> Tue, 27 October 2015 23:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F4961B2CA7 for <>; Tue, 27 Oct 2015 16:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7byZw4Hp1l1L for <>; Tue, 27 Oct 2015 16:02:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E2321B2C9E for <>; Tue, 27 Oct 2015 16:02:36 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.3.377.0; Tue, 27 Oct 2015 16:02:35 -0700
To: Michal Fojtak <>, "" <>
References: <> <> <>
From: Tobias Oberstein <>
Message-ID: <>
Date: Wed, 28 Oct 2015 00:02:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [hybi] Subscription/topic confusion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2015 23:02:39 -0000

Hi Michal,

 > Let's use your chat server analogy. Let's say that I want to create a
> chat room. Such a chat room has to be registered somewhere. If it is not

Good example! It's also easier to discuss having a concrete example.

A "chat room" is more than a topic.

Eg it might have a subject (what's being talked about in the room).

A chat room can _use_ a topic to distribute messages in the room.

Please see below ..

> then nobody knows about it and nobody can publish/subscribe. How can I
> subscribe to something that doesn't exist. And it starts to exist only
> if somebody subscribes to it first. That's a deadlock.

Here is one way to create a WAMP based chat rooms app.

A chat room is created by calling a registered procedure


which returns a room ID, say an integer.

The backend component implementing this will

- track the chat room internally
- publish an event to "" with the ID of 
the room created as payload

The component further registers a procedure


which returns a list of integers with room IDs.

A frontend component will subscribe to "" 
and call "" to get the initial list of rooms, 
and to stay up to date with new rooms being created.

To listen for messages in room 23, the frontend subscribes to 

To say something in room 23, the frontend now calls


and the backend procedure will then publish to "".

The "say" procedure can do more than mere delegated publish. eg 
automatically append something to the content before publishing.

Above is using all 4 core WAMP actions (call, register, publish, 
subscribe). It uses these actions as building blocks to create an 
app-level behavior.

> My chat server should expose all topics that people can discuss.
> Regardless if someone has subscribed to it or not.
> Another real world example - I am developing a Qt-based WAMP client
> library. I am registering Qt objects. I can register objects, methods
> and properties. So far it is lovely. But those objects have signals. Or
> events if you wish. Those are topics in WAMP world. But they exist even
> if nobody has connected a handler to them. Once I register my objects
> with WAMP, they become remote objects. I can call methods, read and
> write properties. But what I need is to be able to query topics(signals)
> that those objects expose.

This example is a very different use case from above chat room thing.

The difference is: with the chat room, it's obvious that a "chat room" 
is an app level thing much more user/app centric than a signal on a Qt 
class - which is much lower level / technical.

And the one aspect you list (reflect on signals exposed by class) is 
only part of the problem.

You likely also want reflection on: what exceptions does a procedure raise?

Maybe also: what procedures does a class call out to (or can in principle)?

Or: what topics does a procedure internally publish to? (e.g. 
create_room procedure publishes to on_create_room).

Because that would then allow to reflect upon a whole API surface, 
including dependencies / use relations between entities.

This use case is what WAMP calls "reflection"

This is totally not hashed out yet;)

I agree that it would lift things to yet another level. Being able to 
reflect on a WAMP based API.

But I think we should try to keep the WAMP core things simple, and add 
reflection capabilities at a meta level.

Like there is a WAMP meta procedure to list sessions:


And we could have a WAMP meta procedure to list topics (and other entities):


App code, like for hooking up a Qt object would require to call


to associate metadata with URIs of topics, procedures and errors.

The metadata of a procedure might include parameter descriptions, help 
text, topics being published to, other procedures being called etc etc

> I hope that the two examples describe my concern that topics exist
> without subscribers. Like procedures exist without callers.

A procedure comes into existance when a callee registers the procedure.
A topic comes into existance when a subscriber subscriber to the topic.
A topic exists without publishers, as does a procedure without callers.

Another way to think of this is:

Producer       Item            Consumers
caller         call            callee
publisher      event           subscriber

Consumers are tracked by necessity, because the router needs to forward 
("route") the item (a call or an event).

There is no necessity for a router to track producers to do it's core 
job of routing.

But as is illustrated from your 2nd example (the Qt class), there _is_ a 
case for reflection (which is higher level than the core routing).



While I think your first example (chat room) is best done using WAMP 
actions as building blocks, I think your 2nd example / use case could be 
addressed by reflection:

Reflection is different from the issue Alex mentioned:

This is _tracking_ actual usage of URIs. I don't think this is a good 
fit to your 2nd example ..

Makes sense?


> Cheers.
> Michal
> On Fri, Oct 23, 2015 at 11:44 AM, Константин Буркалев
> < <>> wrote:
>     Hi Michal!
>>     20 окт. 2015 г., в 18:43, Michal Fojtak <
>>     <>> написал(а):
>>     WAMP protocol defines two main mechanisms - RPC via registrations
>>     and calls, event distribution via subscribe/publish.
>>     Callee can register procedure and such a procedure becomes an
>>     object which is tracked internally by router. Router "is aware" of
>>     registrations. Caller can query registrations via meta API.
>>     HOWEVER
>>     This is not a story of other wamp entity - the topic. Topic as
>>     such is not stored anyware in the router. Router is not aware of
>>     them. Potential subscriber cannot query available topics.
>>     Ironically, you can query subscriptions. But unless somebody
>>     subscribes to it, the topic object exists only in publisher.
>>     It kind of contradicts the main advantage of having a central hub
>>     - router which is aware of all objects - procedures and topics.
>     Well, yep, there may be some confusion about topics. But let’s look
>     at that from different side:
>     For example, in chat servers or irc, clients create topics as they
>     needed, and you can not know which topics will be created in the
>     future. Also, topics (rooms, channels) are created by users only
>     when they first time need them. I don’t know cases, when user is
>     aware of topics, that he will need in future.
>      From this point, WAMP proto is describing common user pattern of work.
>     Also, you can query info about topics in runtime via META API. Of
>     course, there are a lot of gaps in specification about META API, but
>     that is just another part we are working on.
>     In Pub/Sub pattern there is loose coupling between clients and
>     topics, and there is no need for publisher to be aware of how much
>     subscribers are there, or does this topic exist, i mean from
>     technology point of view, but from business side, of course can be
>     such requirements.
>     But in RPC pattern it is necessary condition, because you can not
>     just call some RPC, which doesn’t exist yet. And Callee provides RPC
>     via it’s registration in router.
>      From my point of view, adding topic registration — is just one
>     more, mostly unneeded step. And even if we add it, i, as WAMP
>     implementor, will transparently send a register message to wamp
>     router at first time topic is requested.
>     As i mentioned earlier, we should extend and describe META API for
>     how to retrieve topics list, info and so on.
>>     Would it be possible to "register" topics like we can register
>>     procedures?
>>     We can then get a list of topics. We can define and describe them.
>>     And other useful things.
>>     P.S.: The subscription id is quite confusing as well. It is not
>>     really subscription identification. Router creates this id when a
>>     first subscriber subscribes to the topic. If there was a topic
>>     then we would have topic id and many subscriber ids for each
>>     individual subscriber which models the situation more naturally.
>>     _______________________________________________
>>     hybi mailing list
>> <>
>     С уважением,
>     Константин Буркалев
> <>