Re: [hybi] Subscription/topic confusion

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E13C1B2E70 for <>; Tue, 27 Oct 2015 16:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8D752-scaIkC for <>; Tue, 27 Oct 2015 16:24:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C16CD1B2DFD for <>; Tue, 27 Oct 2015 16:16:49 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.3.377.0; Tue, 27 Oct 2015 16:16:48 -0700
To: =?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0JHRg9GA0LrQsNC70LXQsg==?= <>, Michal Fojtak <>
References: <> <>
From: Tobias Oberstein <>
Message-ID: <>
Date: Wed, 28 Oct 2015 00:16:46 +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: <>
Cc: "" <>
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:24:03 -0000

Hi Konstantin,

> 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.

Exactly. That's the difference.

Technically, there is no need for routers to track publishers to do it's 
core job.

Now, if you decide "chat room" == "topic", then you have essentially 
restricted very much how you chat room can look like and behave. 
Business things. Which means: it's probably unwise to make "chat rooms" 
identical to "topics" in the first place;)

> 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.

Yes. It's a necessity.

A router cannot route a call without knowing about the callee 
beforehand. And a router cannot route an event without knowing about 
subscribers beforehand.

>  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.

Hehe;) But yes, it's again this point: it's technically unecessary info 
for the _core_ job .. routing.

> As i mentioned earlier, we should extend and describe META API for how
> to retrieve topics list, info and so on.

Yep, agreed.

The meta API in general needs more love.

And the "reflection" parts of the WAMP meta API is essentially at the 
"idea only" stage (there is some experimental, minimal code in

Essentially, I started with refletion API just being a store of metadata 
on URIs.

But there should be some usable semantics above that.

E.g. let's say I want to only allow URIs (for procedure, topics, errors) 
in my app which have been declared via reflection API beforehand.

If there is no "additional semantics", then reflection would just be a 
stupid metadata store for URIs, formally/technically unrelated to the 
core routing.

Now I am loud thinking .. this isn't hashed out obviously;)