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

Michal Fojtak <fojtak.michal@gmail.com> Fri, 23 October 2015 06:37 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 651591B2BDD for <hybi@ietfa.amsl.com>; Thu, 22 Oct 2015 23:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 BQwc1NO4iMVU for <hybi@ietfa.amsl.com>; Thu, 22 Oct 2015 23:37:45 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 DB2261AD371 for <hybi@ietf.org>; Thu, 22 Oct 2015 23:37:44 -0700 (PDT)
Received: by ykba4 with SMTP id a4so102761864ykb.3 for <hybi@ietf.org>; Thu, 22 Oct 2015 23:37:44 -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=UQetqr/xJc6d6+sMz1luxtTbgqLAyMJpd5jvSj/heMU=; b=tREJAPfa/eqiRFDU9ALYMe7aMfO+ops1g2Yp0ieC64pMdFulj+6PL4ffAKat9ktagM MoMMisDYwOq5WeNweyGsurUAciYPynyCfm7DwWs4RX0GNaJIbuz1aqZz88eFLxaa3/gS af+FKOWnsBkDx2LW8fkqM7BNkXnOZlpAGJ+qwMsGcxoIcs0SpUtDiarZ/au2RIHxlN2J vAz0YSs/MwC9gIjAUIbbZYI2fCH8QYYMEeNF2s9kXYedc8/BwDsIkmx9bJttLKF4zGKE GsgF97fxypuT+Ihn6wANWECVBMcqOHBSm0pZ11F9bpAInedVFn1Zb4N7lPVe79O4xHg0 aMRA==
MIME-Version: 1.0
X-Received: by 10.13.243.135 with SMTP id c129mr15598111ywf.113.1445582264266; Thu, 22 Oct 2015 23:37:44 -0700 (PDT)
Received: by 10.37.214.79 with HTTP; Thu, 22 Oct 2015 23:37:44 -0700 (PDT)
In-Reply-To: <CAHo5QG+2vi8sYAi+C5LxvJa1Qq9qh793+-+v-L6v1npYWE1crw@mail.gmail.com>
References: <mailman.205.1445367629.30292.hybi@ietf.org> <634914A010D0B943A035D226786325D44CA8AE99F2@EXVMBX020-12.exch020.serverdata.net> <CAHo5QG+2vi8sYAi+C5LxvJa1Qq9qh793+-+v-L6v1npYWE1crw@mail.gmail.com>
Date: Fri, 23 Oct 2015 08:37:44 +0200
Message-ID: <CAHo5QG+Msc4Cw3=tkYj1LWm7VNXigH8H4HGjWqv8Eq405pwSiA@mail.gmail.com>
From: Michal Fojtak <fojtak.michal@gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c035a1c5af8fa0522bfd9a9
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/q1RnqdfIqjncG-PwR0huD3HcfaU>
Subject: Re: [hybi] hybi Digest, Vol 75, Issue 4
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, 23 Oct 2015 06:37:47 -0000

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 <fojtak.michal@gmail.com>
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 <
> alexander.goedde@tavendo.de> wrote:
>
>> >    1. Subscription/topic confusion (Michal Fojtak)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Tue, 20 Oct 2015 17:43:44 +0200
>> > From: Michal Fojtak <fojtak.michal@gmail.com>
>> > To: hybi@ietf.org
>> > 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
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>