[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Hono-Kura integration
|
On Wed, 2018-07-04 at 16:28 +0000, De Alti, Cristiano wrote:
> Hi Kai,
> I agree that option #2 is the one which is the most consistent with the
> current topic conventions.
>
> Before deciding, I would like to explain how the “gateway” concept is currently
> implemented in Kura and Kapua.
> Kura would publish data on behalf of downstream “assets”, which is an
> application level concept in Kura and Kapua, on the following topic:
>
> t/${tenant-id}/${kura-device-id}/W1/A1/${asset-name}
>
> and, as Kura always authenticate to Hono, the second and third levels of the
> topic are redundant and could be elided according to option #2:
>
> a. t///W1/A1/${asset-name}
>
> As far as I understand, the Hono-way to publish data on behalf of “downstream
> devices”, which are first class citizens, would be:
>
> t/${tenant-id}/${asset-name}/W1/A1
>
> which I guess could be easily understood by a (modified) Kapua “asset”
> consumer.
> For the same reasoning below, I think that the tenant-id could be elided,
> resulting in:
>
> b. t//${asset-name}/W1/A1
>
> which is even more compact than a.
>
> Is this confusing?
>
No, in fact, this makes total sense and would be even better from a Hono
perspective because it would fully comply with Hono's "gateway" concept.
Note, however that for this to work, the assets indeed need to be registered as
devices so that Hono can use the asset-name and the Kura gateway's device ID when
asserting the asset's registration status using the Device Registration API.
> Ciao,
> Cristiano
>
> On 6/29/18, 14:55, "hono-dev-bounces@xxxxxxxxxxx on behalf of Hudalla Kai
> (INST/ECS4)" <hono-dev-bounces@xxxxxxxxxxx on behalf of kai.hudalla@xxxxxxxxxxx
> m> wrote:
>
> On Thu, 2018-06-28 at 17:32 +0000, De Alti, Cristiano wrote:
> > Hi,
> > I’m talking about the MQTT adapter (“t” and “e” topics are not used in
> the
> > Kura adapter).
>
> true
>
> > In my proposal below I did not dare to suggest the most obvious fix:
> creating
> > entirely new topic prefixes allowing to publish e.g. T/${topic-suffix}
> and
> > E/${topic-suffix}.
> > ;-)
> >
>
> well, I will have to think about this a little more in depth but I at first
> glance option 2 seems to be the one that would be most consistent with our
> current approach in that we would not need to introduce special handling
> for the
> topic's "path length" but could stick to using the "/" as the separator. We
> would
> then simply need to consider a "null" tenant and device ID as "use the
> tenant and
> device ID that have been resolved during authentication".
>
> We already allow additional segments in the topic path following the first
> three
> segments, thus I believe it wouldn't be too hard to do. WDYT?
>
> > Thanks,
> > Cristiano
> >
> > Regards,
> > Cristiano
> >
> > On 6/27/18, 18:13, "hono-dev-bounces@xxxxxxxxxxx on behalf of Hudalla Kai
> > (INST/ECS4)" <hono-dev-bounces@xxxxxxxxxxx on behalf of kai.hudalla@bosch
> -si.co
> > m> wrote:
> >
> > On Wed, 2018-06-27 at 15:18 +0000, De Alti, Cristiano wrote:
> > > Hi,
> > > I wonder if there is still room for an improvement in the MQTT
> topic
> > format
> > > for telemetry and event.
> > >
> >
> > Are we talking about the existing Kura adapter or the MQTT adapter?
> >
> > > Kura would always authenticate to Hono, and does not use the Hono
> > “gateway”
> > > concept.
> > > Having to use the “extended” topic form is unfortunate as it wastes
> two
> > extra
> > > bytes (“t/”) compared to the Kura/Kapua “data messages”.
> > >
> > > Shrinking the topic to the minimum will benefit people connecting
> over a
> > > cellular link on a cheap (and limited) data plan, and being able to
> use
> > > “t/${topic-suffix}” would represent a significant cost saving.
> > >
> > > As this “compact” form is ambiguous and cannot be used, I wonder If
> one
> > of the
> > > following alternatives (in order of preference) could be added to
> the
> > current
> > > topic rules
> > >
> > > 1. t//$topic-suffix}. Two adjacent topic separators are explicitly
> > allowed in
> > > section 4.7.1.1, Topic level separator, of the 3.1.1 spec,
> delimiting a
> > zero-
> > > length topic level.
> > > It would indicate “this tenant-id and device-id”
> > > 2. t///$topic-suffix}. As above but with two zero-length topic
> levels
> > > indicating “this tenant-id” and “this device-id” respectively
> > > 3. t/_/$topic-suffix}. The “_” placeholder is used to indicate
> “this
> > tenant-id
> > > and device-id”
> > > 4. t/_/_/$topic-suffix}. Same as above but using two levels to
> indicate
> > “this
> > > tenant-id” and “this device-id” respectively
> > >
> > > As said above, 1 and 2 would be preferred but I’ve never tried to
> publish
> > such
> > > topics, so I don’t know yet if they could be problematic for some
> client
> > > implementations.
> > > The last two forms, 3 and 4, are definitely less problematic.
> > > Maybe all four should be supported.
> > >
> > > Regards,
> > > Cristiano
> > >
> > > _______________________________________________
> > > hono-dev mailing list
> > > hono-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or
> unsubscribe
> > from
> > > this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/hono-dev
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/hono-dev
> >
> >
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/hono-dev
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
>
>
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
