Re: [hybi] Subscription/topic confusion

Tobias Oberstein <tobias.oberstein@tavendo.de> Sat, 31 October 2015 14:20 UTC

Return-Path: <tobias.oberstein@tavendo.de>
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 6526C1B3882 for <hybi@ietfa.amsl.com>; Sat, 31 Oct 2015 07:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 FJT249auV22f for <hybi@ietfa.amsl.com>; Sat, 31 Oct 2015 07:20:25 -0700 (PDT)
Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928061A1AA6 for <hybi@ietf.org>; Sat, 31 Oct 2015 07:20:25 -0700 (PDT)
Received: from [192.168.1.142] (88.217.38.70) by smtpx20.serverdata.net (206.225.164.36) with Microsoft SMTP Server (TLS) id 8.3.377.0; Sat, 31 Oct 2015 07:20:24 -0700
To: Michal Fojtak <fojtak.michal@gmail.com>, "hybi@ietf.org" <hybi@ietf.org>
References: <CAHo5QGKkd2PGruw0VaRh_gd7M5o7FdDbLrcfnEQTNbYy3fAQQg@mail.gmail.com> <4F44FE84-BA12-4F1A-B471-CE1797ABBC82@gmail.com> <CAHo5QG+_HwVzGxtxykueD0RPBHtzTANE4W5-pgHaGY=-TigUYQ@mail.gmail.com> <56300283.6080306@tavendo.de> <CAHo5QGK-EqAV=xtRmYK+_3VPPwi+dMiA9tO9gjzpbdrockGW7w@mail.gmail.com>
From: Tobias Oberstein <tobias.oberstein@tavendo.de>
Message-ID: <5634CE25.4000604@tavendo.de>
Date: Sat, 31 Oct 2015 15:20:21 +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: <CAHo5QGK-EqAV=xtRmYK+_3VPPwi+dMiA9tO9gjzpbdrockGW7w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/GfSGQ4aRLYvawCBdlp8CKryP8cc>
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: Sat, 31 Oct 2015 14:20:27 -0000

> 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

Correct. The caller is a producer of calls, whereas the callee is a 
consumer of calls.

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

No, a callee is a producer of call _results_. And a caller is a consumer 
of call results.

But I guess this is more about "naming things" than anything: maybe it 
would be better to use the words "source" and "sink", instead of 
"producer" and "consumer"?

> 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

"no" what (some text missing)? no subscribers? If so: this is nothing a 
publisher should be concerned about, because of the decoupling. It's the 
router that will recognize a publication on a topic with no subscribers, 
and simply do nothing ("throw away the event"). But maybe I didn't get 
your question?

> What I am mainly after is to understand procedure and topic meata api.

Yep, from what I understand about your use case / itch, it's the 
reflection parts of the WAMP meta API that would fit best for you.

> Maybe it is all just about semantics.
> Also, the specification is changing quite dynamically.

There are parts of the WAMP spec which are not yet hashed out: parts of 
the "advanced profile" (WAMP AP). And one such area is the WAMP meta 
API. And the reflection part of the former is merely at "sketch stage".

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

I have added your comments here:

https://github.com/wamp-proto/wamp-proto/issues/61#issuecomment-152739199

Touching on one aspect: "wamp.reflect.define" would define metadata 
about a topic/procedure/error URI, and the original idea was to have the 
submitted info contain also the URI type. E.g. submit a JSON schema 
thing to "wamp.reflect.define".

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

Yes, agreed. It's an important area.

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

Exactly. The degree of completeness/polish over the different features 
in the WAMP AP is varying. The approach is one of 
co-design/-implementation: immediately implement even working sketches, 
gain experience, and iterate to refine the spec.

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

Yes, it does help. It's exactly this feedback and input from 
implementors and app developers we need .. thanks for chiming in!

Cheers,
/Tobias