Subject: [hybi] Subscription/topic confusion

From: Michal Fojtak <[email-masked]>
Date: Tue, 20 Oct 2015 17:43:44 +0200

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.

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.

---

From: Константин Буркалев <[email-masked]>
Date: Fri, 23 Oct 2015 12:44:06 +0300

Hi Michal!

> 20 окт. 2015 г., в 18:43, Michal Fojtak <[email-masked]> написал(а):
> 
> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

С уважением,
Константин Буркалев
[email-masked]

---

From: Michal Fojtak <[email-masked]>
Date: Fri, 23 Oct 2015 17:02:23 +0200

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

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, Константин Буркалев <
[email-masked]> wrote:

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

---

From: Константин Буркалев <[email-masked]>
Date: Sun, 25 Oct 2015 12:02:25 +0300

Hi, Michal!

> 23 окт. 2015 г., в 18:02, Michal Fojtak <[email-masked]> написал(а):
> 
> 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, Константин Буркалев <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Michal!
> 
> 
>> 20 окт. 2015 г., в 18:43, Michal Fojtak <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/hybi <https://www.ietf.org/mailman/listinfo/hybi>
> 
> 
> С уважением,
> Константин Буркалев
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 

Cheers.
Konstantin.

---

From: Michal Fojtak <[email-masked]>
Date: Tue, 27 Oct 2015 08:41:28 +0100

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, Константин Буркалев <
[email-masked]> wrote:

> 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.
>
> 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.
> 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.
>
>
>> 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
>> It kind of contradicts the main advantage of having a central hub -
>> router which is aware of all objects - procedures and topics.
>>
>>
>> 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.
>> 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

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 27 Oct 2015 23:09:45 +0100

Am 20.10.2015 um 17:43 schrieb Michal Fojtak:
> which is tracked internally by router. Router "is aware" of
> registrations. Caller can query registrations via meta API.
>
> HOWEVER

The analogy is as follows:

callee registers a procedure at a router, which results in a "registration"

subscriber subscribes to a topic at a router, which results in a 
"subscription"

both registrations and subscriptions can be listed via the WAMP meta API

neither callers nor publishers are tracked at the router until there is 
an actual call from a caller, or an event published by a publisher.

neither callers nor publishers can be listed

> subscription identification. Router creates this id when a first

Yes, it is. Please see below ..

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

The subscription ID identifies the subscription that is managed by the 
broker.

The topic being subscribed to is only _one_ part of a subscription. E.g. 
the matching strategy (eg exact-match vs prefix-match) is also part of 
the subscription.

There can be 2 subscriptions with the _same_ topic, but different 
matching policies.

In fact, separating "subscription" from "topic" was a major change we 
did when moving from WAMP v1 to v2.

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 28 Oct 2015 00:02:27 +0100

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.

> 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, Константин Буркалев
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Michal!
>
>
>>     20 окт. 2015 г., в 18:43, Michal Fojtak <[email-masked]
>>     <mailto:[email-masked]>> написал(а):
>>
>>     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
>>     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.
>
>     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.
>     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.
>
>>
>>     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.

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 28 Oct 2015 00:16:46 +0100

Hi Konstantin,

> 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;)

> call some RPC, which doesn’t exist yet. And Callee provides RPC via it’s

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.

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

> 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 Crossbar.io).

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;)

Cheers,
/Tobias

---

From: Michal Fojtak <[email-masked]>
Date: Fri, 30 Oct 2015 13:28:50 +0100

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

>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 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 <
[email-masked]> wrote:

> - publish an event to "com.example.chat.on_create_room" with the ID of the
> room created as payload
>
> subscribe). It uses these actions as building blocks to create an app-level
> behavior.
>
>
> 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.
>
> Or: what topics does a procedure internally publish to? (e.g. create_room
> procedure publishes to on_create_room).
>
> There is no necessity for a router to track producers to do it's core job
> of routing.
>
> 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
>>

---

From: Tobias Oberstein <[email-masked]>
Date: Sat, 31 Oct 2015 15:20:21 +0100

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

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.

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

>         13.3.12
>         <https://tools.ietf.org/html/draft-oberstet-hybi-tavendo-wamp-02#section-13.3.12>.
>         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.

>             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