Re: [hono-dev] Hono-Kura integration

["De Alti, Cristiano" <Cristiano.DeAlti@xxxxxxxxxxxx>]

Hi,
  I’m talking about the MQTT adapter (“t” and “e” topics are not used in the Kura adapter).
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}.
;-)

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@xxxxxxxxxxxx> 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