Re: [hybi] hybi Digest, Vol 75, Issue 4

[Michal Fojtak <[e-mail]>]

There is an alternative and maybe more elegant solution:
1. Let's keep EVENT intact and the implementer decides wether 1:1 or 1:many
subscriptionId. I recommend 1:1. Registration is simply registration and
not a group of registrations.
2. Reuse REGISTER message to register topic. Use Option to specify that uri
being registered is a topic. Like so:
          [REGISTER, Request|id, {"isTopic": true}, Procedure|uri]
3. The Topic Reflection documentation should be updated. Also
wamp.registration.get should then return:

RegistrationDetails :=
       {
           "id": registration|id,
           "created": time_created|iso_8601_string,
           "uri": procedure|uri,
           "match": match_policy|string,
           "invoke": invocation_policy|string

           "isTopic": topic_or_procedure|bool
       }

Btw. why the registration detail contains invocation policy. Isn't it
up to the router how it invokes procedures in case of multiple
registrations to the same uri?


On Thu, Oct 22, 2015 at 4:26 PM, Michal Fojtak <[e-mail]>
wrote:

> Thank you for the reaction and for pointing me to the relevant gihub issue.
>
> > As stated in the spec, the advantage of the latter is that it allows
> serializing an event once for all subscribers
>
> If we accept the idea of topics being persisted and discoverable then this
> is not a problem either. The serialized event stays the same. But instead
> of using subscription id, we would use topic id.
>
> Instead of this:
>
> [EVENT, SUBSCRIBED.Subscription|id, PUBLISHED.Publication|id, Details|dict]
>
>
> There would be this:
>
> [EVENT, TOPIC_REGISTERED.topicId, PUBLISHED.Publication|id, Details|dict]
>
>
> The subscription id should be unique to each subscriber-topic. If the subscriber subscribes to another topic, a new subscribtion id should be generated.
>
> I see a subscription as an analogy to an event handler.
>
>
> I understand that the above would require a big change:
>
> 1. New message - REGISTER_TOPIC
>
> 2. Response -  TOPIC_REGISTERED returning topicId to the publisher.
>
> 3.   Change the EVENT message such that it holds topicId
>
>
> On the other hand if there is still a chance to have an impact on the WAMP protocol spec - if there is still a time - let's do it and prevent any problems in the future
>
>
>
> On Wed, Oct 21, 2015 at 5:48 PM, Alexander Gödde <
> [e-mail]> wrote:
>
>> >    1. Subscription/topic confusion (Michal Fojtak)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Tue, 20 Oct 2015 17:43:44 +0200
>> > From: Michal Fojtak <[e-mail]>
>> > To: [e-mail]
>> > Subject: [hybi] Subscription/topic confusion
>> > Message-ID:
>> >       <CAHo5QGKkd2PGruw0VaRh_gd7M5o7FdDbLrcfnEQTNbYy3fAQQg
>> > @mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > 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.
>> >
>>
>> First of all: Thanks for chiming in regarding WAMP!
>>
>> It would indeed be useful to register topics to enable discovery.
>> While there are no implementations, there is discussion of this at
>> https://github.com/wamp-proto/wamp-proto/issues/76
>>
>> If you have any more detailed suggestions, then please add them there to
>> get the conversation going again.
>>
>> > 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.
>>
>> The spec currently leaves it open to implementations whether the
>> relationship between subscriptionIDs and actual subscribed clients is
>> 1-to-1 or one-to-many.
>>
>> As stated in the spec, the advantage of the latter is that it allows
>> serializing an event once for all subscribers (if they receive the event
>> based on the same subscription topic/matching policy, and use the same
>> serialization). With serialization being a significant amount of the work
>> the broker does, this is a big advantage.
>>
>> Regards,
>>
>> Alexander Gödde
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>