Re: [hybi] Subscription/topic confusion

Michal Fojtak <fojtak.michal@gmail.com> Fri, 30 October 2015 12:28 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 A91BA1B2AF0 for <hybi@ietfa.amsl.com>; Fri, 30 Oct 2015 05:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level:
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 DnafgUhJow22 for <hybi@ietfa.amsl.com>; Fri, 30 Oct 2015 05:28:51 -0700 (PDT)
Received: from mail-yk0-x241.google.com (mail-yk0-x241.google.com [IPv6:2607:f8b0:4002:c07::241]) (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 656EE1B2AB7 for <hybi@ietf.org>; Fri, 30 Oct 2015 05:28:51 -0700 (PDT)
Received: by ykba4 with SMTP id a4so6117591ykb.3 for <hybi@ietf.org>; Fri, 30 Oct 2015 05:28:50 -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=4+T5K+k+8ZwWqf//My01qu31AYp6Mt7t6mNhz9dqQ/Q=; b=Tgg+1cGipycOYKd7RAFZT0AyPEbhAFVAAAF7fq1v3CHLbwJgvLZoBMj4BSW0JWWDaP u/I3NtzMe7P5SwLTILYZDRUPQc+qXeJ4x7QD+l2QW6jJlB2+79wxa+9++dEVOwpJ1wDK 4Z543YuGdBOitavPG+Vc34UwWdRujSked+aHIS7om8JiK06h7qG0n5j7Ml+gjfSJ7YYv tnhxDy1ASQs137prFTjEylxykvu5FaaCykFf3lvrfG0cV55Q8FbkjmYPeKZOf8jOz2xk 1iFxDAEu0k8Kn4afyeVhiw0w8rZwhNeMqC2IQkz7TO6H3oAdE4SkktltVDTnoXVKzqAa mZeA==
MIME-Version: 1.0
X-Received: by 10.129.31.197 with SMTP id f188mr5875614ywf.94.1446208130756; Fri, 30 Oct 2015 05:28:50 -0700 (PDT)
Received: by 10.37.214.79 with HTTP; Fri, 30 Oct 2015 05:28:50 -0700 (PDT)
In-Reply-To: <56300283.6080306@tavendo.de>
References: <CAHo5QGKkd2PGruw0VaRh_gd7M5o7FdDbLrcfnEQTNbYy3fAQQg@mail.gmail.com> <4F44FE84-BA12-4F1A-B471-CE1797ABBC82@gmail.com> <CAHo5QG+_HwVzGxtxykueD0RPBHtzTANE4W5-pgHaGY=-TigUYQ@mail.gmail.com> <56300283.6080306@tavendo.de>
Date: Fri, 30 Oct 2015 13:28:50 +0100
Message-ID: <CAHo5QGK-EqAV=xtRmYK+_3VPPwi+dMiA9tO9gjzpbdrockGW7w@mail.gmail.com>
From: Michal Fojtak <fojtak.michal@gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=001a11425ce2e7bb1a0523519143
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/BE7sPw25rc2XrzjU5rweCCRmsC4>
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: Fri, 30 Oct 2015 12:28:55 -0000

Hi Tobias,

Let me add some commnets to your points:

There seems to be a fundamental misunderstanding of how we see this.
Please, let me express it using one of your (I belive important) comments:

Producer       Item            Consumers
--------------------------------------------
caller         call            callee
publisher      event           subscriber

>From the table above it suggests that a caller is a producer of a data.
But it only produces a request for data - the call. We need to take a look
on who produces the data:
Souldn't the table look like this?

Producer       Item            Consumers
--------------------------------------------
callee         result           caller
publisher      event           subscriber

Publisher produces data consumed by subscriber.
Callee produces data consumed by caller.

We all agree that publishers and subscribers are loosely coupled and do not
need to know about each other as I pointed out in my last post. Btw., the
publisher should still have a chance to stop publish if there are no

What I am mainly after is to understand procedure and topic meata api.
Maybe it is all just about semantics.
Also, the specification is changing quite dynamically.

Sometimes, the spec is misleading. E.g.:

13.3.12 <https://tools.ietf.org/html/draft-oberstet-hybi-tavendo-wamp-02#section-13.3.12>.
Procedure Reflection also talks about topic reflection.

 or

wamp.reflection.topic.list - where is the list coming from? How are
topics persisted? Or does it list only those previously defined? -
Actually why not, maybe that's where my "topic registration is"?

 or

wamp.reflection.topic.describe and wamp.reflect.describe - what is the
difference between the two?

wamp.reflect.define - how do I specify if I want to define procedure
or topic? Or should the information be stored in the definition
itself?


The meta api and reflection is a very important aspect of a good SOA
gateway/router/hub.

It is important for me because (as specs points out):

 o  documentation

   o  discoverability (what applications are registered, what
functionalities they offer)

   o  generating stubs and proxies (for Qt objects, generic UI for
procedures and events)


I can see that you guys do first things first and the reflection and
meta api is still a sketch.

I hope that this chat might help do refine this piece of protocol.


Cheers.

Michal


On Wed, Oct 28, 2015 at 12:02 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> 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
>
> "com.example.chat.create_room"
>
> which returns a room ID, say an integer.
>
> The backend component implementing this will
>
> - track the chat room internally
> - publish an event to "com.example.chat.on_create_room" with the ID of the
> room created as payload
>
> The component further registers a procedure
>
> "com.example.chat.list_rooms"
>
> which returns a list of integers with room IDs.
>
> A frontend component will subscribe to "com.example.chat.on_create_room"
> and call "com.example.chat.list_rooms" 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
> "com.example.chat.room.23"
>
> To say something in room 23, the frontend now calls
>
> "com.example.chat.room.23.say"
>
> and the backend procedure will then publish to "com.example.chat.room.23".
>
> 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"
>
> https://github.com/wamp-proto/wamp-proto/issues/61
>
> 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:
>
> wamp.session.list
>
> And we could have a WAMP meta procedure to list topics (and other
> entities):
>
> wamp.reflection.list
>
> App code, like for hooking up a Qt object would require to call
>
> wamp.reflection.declare
>
> 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).
>
> --
>
> Summary:
>
> 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:
>
> https://github.com/wamp-proto/wamp-proto/issues/61
>
> Reflection is different from the issue Alex mentioned:
>
> https://github.com/wamp-proto/wamp-proto/issues/76
>
> This is _tracking_ actual usage of URIs. I don't think this is a good fit
> to your 2nd example ..
>
> Makes sense?
>
> Cheers,
> /Tobias
>
>
>
>> Cheers.
>>
>> Michal
>>
>> On Fri, Oct 23, 2015 at 11:44 AM, Константин Буркалев
>> <kostik.hunter@gmail.com <mailto:kostik.hunter@gmail.com>> wrote:
>>
>>     Hi Michal!
>>
>>
>>     20 окт. 2015 г., в 18:43, Michal Fojtak <fojtak.michal@gmail.com
>>>     <mailto: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 <mailto:hybi@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/hybi
>>>
>>
>>
>>     С уважением,
>>     Константин Буркалев
>>     kostik.hunter@gmail.com <mailto:kostik.hunter@gmail.com>
>>
>>
>>
>>
>>
>