Re: [hono-dev] Adapt Telemetry/Event API to reflect removal of Hono Mess

[Dejan Bosanac <dejanb@xxxxxxxxxxxx>]

I’m probably missing something, but I can’t find where we deprecated it. The release notes states that adapters now “can” connect directly and that’s about it. And the original discussion thread is left with the note that we should keep it for this use case.

I’m not against deprecating it. We’re losing “external adapters” use case, but no one is interested in that at the moment, so one less bit to maintain. If there’s a consensus that we should do it, let’s make more explicit in docs, release notes and code.

On Mon, Nov 5, 2018 at 1:10 PM Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote:

On Mon, 2018-11-05 at 12:20 +0100, Dejan Bosanac wrote:
> Hi,
>
> I agree that current definitions could be confusing for the people coming first
> time to the project and seeing components that are not used (much) anymore.
> IIRC we agreed that we’ll keep Hono Messaging service for the cases of
> external/custom protocol adapters. Are we still planning to do so?

Well, we have deprecated Hono Messaging with 0.7 and I would rather remove it
from Hono <= 1.0 altogether ...

>  If yes, then maybe we can:
>
> * change API definitions as Kai suggested, as from the APIs perspective “Hono
> messaging” isn’t important anymore
> * document “Hono messaging” component as an optional part of protocol adapters
> and how it can be used in a setup with external protocol adapters. Maybe we can
> have a separate page about protocol adapter basic architecture?
>
> On Mon, Nov 5, 2018 at 11:12 AM Hudalla Kai (INST/ECS4) <
> kai.hudalla@xxxxxxxxxxxx> wrote:
> > Hi list,
> >
> > when we originally created the Telemetry and Event APIs, we did not (yet)
> > have
> > the clean separation between Hono and the AMQP Messaging Network. This was
> > also
> > reflected in the API definitions, e.g. the southbound operations (used by
> > protocol adapters to send data downstream) referred to "Hono's
> > Telemetry/Event
> > endpoint" when if fact the protocol adapters connect to the AMQP Messaging
> > Network (because there is no Hono Messaging anymore). The same applies to the
> > northbound operations. IMHO we should therefore adapt the APIs and explicitly
> > mention the AMQP Messaging Network as the container that the adapters and
> > downstream consumers need to connect to. In the end, all we are doing is
> > defining
> > a set of addresses and properties for sending/receiving messages "the Hono
> > style"
> > (which has a lot of value in my opinion) over the AMQP Messaging Network.
> > However, I think it would help with making the responsibilities of the
> > Protocol
> > Adapters vs. the AMQP Messaging Network more explicit.
> >
> > WDYT?
> >
> > --
> > Mit freundlichen Grüßen / Best regards
> >
> > Kai Hudalla
> > Chief Software Architect
> >
> > Bosch Software Innovations GmbH
> > Ullsteinstr. 128
> > 12109 Berlin
> > GERMANY
> > www.bosch-si.com
> >
> > Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg;
> > HRB
> > 148411 B
> > Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing
> > Directors:
> > Dr. Stefan Ferber, Michael Hahn
> >
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from
> > this list, visit
> > https://www.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://www.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://www.eclipse.org/mailman/listinfo/hono-dev

--

Regards
--
Dejan Bosanac
http://sensatic.net/about