[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Hono-Kura integration
|
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?
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@xxxxxxxxxxxx> 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@xxxxxxxxxxx
> 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
