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