Re: [hybi] Subscription/topic confusion

Michal Fojtak <fojtak.michal@gmail.com> Tue, 27 October 2015 07:41 UTC

Return-Path: <fojtak.michal@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1099A1B3749 for <hybi@ietfa.amsl.com>; Tue, 27 Oct 2015 00:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6shBgPryw3sO for <hybi@ietfa.amsl.com>; Tue, 27 Oct 2015 00:41:29 -0700 (PDT)
Received: from mail-yk0-x244.google.com (mail-yk0-x244.google.com [IPv6:2607:f8b0:4002:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128A21B374C for <hybi@ietf.org>; Tue, 27 Oct 2015 00:41:29 -0700 (PDT)
Received: by ykba4 with SMTP id a4so17507433ykb.3 for <hybi@ietf.org>; Tue, 27 Oct 2015 00:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5rA5qnb97mu5ri+9HS4Kfi0VZeMuJL0u8AhCyem6JW4=; b=fWz3d35YWebDJqaPwGg+sds83CA/VeqpXWYp4MbxDiQMuwdQqbiyAFFH57DPLMzEtk Z+Thq80r3kwf+mgwXswxQvfuUEpNQKfl7fkzLO19yQDLJ5SkWrSpg46RfRHSJbif9/jB 8j29+BqX6yzG6KUhYCxnCxAd/HQBtL365b1/wG+Ls/8lK8RZkA+xEp1LGaEBUxAHX9IO MltKw60WInQVI3yFexeH2oMuQ9ROZVrlOod58y0sOGHOvdUrjKS7OlhZ6Zo0aF3xnXnT m1drySU8pJmkbhb1Ggv0mVu7TYncGKmQC5nNss2NsgzCqD+0cFJ0T3ogz6wFqtGVMQrf sajQ==
MIME-Version: 1.0
X-Received: by 10.129.123.194 with SMTP id w185mr15804768ywc.248.1445931688308; Tue, 27 Oct 2015 00:41:28 -0700 (PDT)
Received: by 10.37.214.79 with HTTP; Tue, 27 Oct 2015 00:41:28 -0700 (PDT)
In-Reply-To: <284EDB6B-0D0E-4393-BCDA-4B8FF93AF6DB@gmail.com>
References: <CAHo5QGKkd2PGruw0VaRh_gd7M5o7FdDbLrcfnEQTNbYy3fAQQg@mail.gmail.com> <4F44FE84-BA12-4F1A-B471-CE1797ABBC82@gmail.com> <CAHo5QG+_HwVzGxtxykueD0RPBHtzTANE4W5-pgHaGY=-TigUYQ@mail.gmail.com> <284EDB6B-0D0E-4393-BCDA-4B8FF93AF6DB@gmail.com>
Date: Tue, 27 Oct 2015 08:41:28 +0100
Message-ID: <CAHo5QGLY-1Z6-p2y6PEjg4gHZCt4qy90J51XApuNpWLaWhQ2hA@mail.gmail.com>
From: Michal Fojtak <fojtak.michal@gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="001a11493904a6b9cd05231134ec"
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/m46b5_miJDbhvxnvtwbzobEGJPA>
Subject: Re: [hybi] Subscription/topic confusion
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2015 07:41:32 -0000

Hi Konstantin,

*> Well, let’s see: if you just register a topic, but do not subscribe
to it — it means nothing :) *

Does that mean that registering a procedure without calling it means
nothing? :-)


*> So, roughly, we can assume that subscribing to topic for a first
time is also a kind of registering it at router.*

How can you subscribe to such a topic prior registration? Where do you
get it's URI? Again - calling a procedure for the first time means you
are registering it?


*> Next question is — how a client can get a list of all topics, that
exists on router — for that there is META API.*

Of course. I have never meant anything else. "wamp.topic.list" META
procedure would do the job.


*> I don’t know does it make sense to publish events to topics, that
no one is interested in?*

Yes, it does. Because in publisher/subscriber paradigm - the publisher
doesn't know about subscribers. Publisher doesn't care if somebody is
subscribed. But the publisher might still optimize and listen to
wamp.subscription.on_subscribe and wamp.subscription.on_unsubscribe in
combination with wamp.subscription.count_subscribers. And when last
subscriber unsubscribes, it stops publishing. And when first
subscriber subscribes, it could start publishing.

But such an optimization should not be mandatory for publishers.
Publisher should decide. Something you want to pass an event to Router
even without subscribers - for logging purposes.


Cheers.

Michal


On Sun, Oct 25, 2015 at 10:02 AM, Константин Буркалев <
kostik.hunter@gmail.com> wrote:

> Hi, Michal!
>
> 23 окт. 2015 г., в 18:02, Michal Fojtak <fojtak.michal@gmail.com>
> написал(а):
>
> 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.
>
>
> Well, let’s see: if you just register a topic, but do not subscribe to it
> — it means nothing :) So, roughly, we can assume that subscribing to topic
> for a first time is also a kind of registering it at router.
>
> Next question is — how a client can get a list of all topics, that exists
> on router — for that there is META API.
>
>
> My chat server should expose all topics that people can discuss.
> Regardless if someone has subscribed to it or not.
>
>
> Mmm, yes, you a talking about a kind of sticky topics, that exist even
> without subscribers. For chat app that is a real case. But WAMP is more of
> general purpose pub/sub system^ and right now doesn’t have a such kind of
> functionality. I don’t know is it really needed. Lets see what other
> participants think of it.
> My opinion is that registering a topic is unnecessary, cause subscribing
> to it is enough.
>
>
>
> 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.
>
>
> I don’t know does it make sense to publish events to topics, that no one
> is interested in? We have an option for persisting events (some kind of
> events history) in advanced profile, and may be in that context it can be
> useful.
>
>
> I hope that the two examples describe my concern that topics exist without
> subscribers. Like procedures exist without callers.
>
> Cheers.
>
> Michal
>
> On Fri, Oct 23, 2015 at 11:44 AM, Константин Буркалев <
> kostik.hunter@gmail.com> wrote:
>
>> Hi Michal!
>>
>>
>> 20 окт. 2015 г., в 18:43, Michal Fojtak <fojtak.michal@gmail.com>
>> написал(а):
>>
>> 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
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>>
>> С уважением,
>> Константин Буркалев
>> kostik.hunter@gmail.com
>>
>>
>>
>>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>
> Cheers.
> Konstantin.
>
>