Re: [hybi] Subscription/topic confusion

Michal Fojtak <> Fri, 23 October 2015 15:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 23B751A0011 for <>; Fri, 23 Oct 2015 08:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.701
X-Spam-Level: *
X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NT4PWLCXGCPK for <>; Fri, 23 Oct 2015 08:02:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 251C01A1EFC for <>; Fri, 23 Oct 2015 08:02:24 -0700 (PDT)
Received: by ykba4 with SMTP id a4so9679805ykb.3 for <>; Fri, 23 Oct 2015 08:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VJ9J27yRCNelTspNt4vIbM2pV5SZzvfzXyVRlX5Pycs=; b=TrP35V9g51ICvcBZ7MMA87yCInfjJUyjQ6tV8DuwegImR+j77IYC/D0NCe4NCjwOIT k7PCUz4gu0bh62bNS3AjtpCenEGKg6Ua1eI7IBO3QW/1HbPjJPsEl9bneFW2oQWqh2Fa 1qLRkvAFGLPrnrW+y47CTEokr39g5/fVISnYhwMjIjad8hPE+CNbHHe2+O1VcrhwpGiA 1PrRrf7hG7Soi94TDgaaTyGpT6rHsBVxSbs7zrYd76hf0L2MhJU9M5NEXQKQOyQgnLdj pVat5VAFkdDikdOE6VIAwluKWW+4cDK2PYvYAZgtmRQGUT4F9+HmgLFWppadD+0BsLmI I27Q==
MIME-Version: 1.0
X-Received: by with SMTP id w185mr2680383ywc.248.1445612543354; Fri, 23 Oct 2015 08:02:23 -0700 (PDT)
Received: by with HTTP; Fri, 23 Oct 2015 08:02:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 23 Oct 2015 17:02:23 +0200
Message-ID: <>
From: Michal Fojtak <>
Content-Type: multipart/alternative; boundary=001a11493904212f760522c6e643
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: Fri, 23 Oct 2015 15:02:35 -0000

Hi Konstantin,

Thank you for your post.
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 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.

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

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



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.
> 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
> С уважением,
> Константин Буркалев