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

["Hudalla Kai (INST/ECS4)" <kai.hudalla@xxxxxxxxxxxx>]

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