| Re: [hono-dev] Let's get started |
Hi Dejan,I am really glad to see you guys pop up on the mailing list. I almost thought you already had lost interest when I posted yesterday ;-)Some introductory words regarding the initial code contribution. The code simply reflects the functionality we had been implementing with the constraint that we had to deploy it to Cloud Foundry using the existing RabbitMQ message broker provided by Pivotal as part of the runtime. Personally, I do not need any of that code to remain as is. It was just meant as a starting point to spark off the discussion about how we _really_ want to build Hono. And it obviously has fulfilled that purpose :-)Coming back to your (excellent) questions/ideas, see below ...
I looked a bit at the initial code yesterday. I think it’d be good to discuss some basic ideas while we’re still in early stage.Definitely!As far as I can see, ConnectorClient is the main abstraction that represent the entry point to our system (both southbound and northbound). It’s an API against which folks should write services and adapters. This looks good so far, we can refine it as we go and see what’s missing.This is only true for the current code base. However, I do not think that the client component should be the driving factor for Hono's external API (also see my comment below).The one question I have is how did you envision to have multiple implementations of this API and people deploying the one they are interested in? Should we have some kind of discovery mechanism?I think we should implement a service component exposing an AMQP 1.0 based interface that serves as a facade to the underlying (and exchangable) messaging infrastructure. That could be (as a starting point) ActiveMQ or RabbitMQ (important for Bosch) but I would also like to see Kafka being employed for at least the upstream Telemetry traffic. Clients can then use any AMQP 1.0 client component they see fit but we can also provide a client particularly designed to be used with Hono if that is feasible.During deployment you can then select and configure the particular messaging provider(s) you want to use for your Hono instance. Does that make sense to you?Also, I don’t see any support for protocols adapters yet. I assume they would run like a separate services, listening for messages and calling the api to send them further up the stack. Is that right?That is correct. I see them as separate components/services running (and scaling) independently from the Hono processes. Communication between Protocol Adapters and Hono should then be AMQP 1.0 based.One more idea we can consider is to provide a protocol API based on AMQP 1.0, where we don’t specify library API, but the message formats that are exchanged with the system. This would give us some additional benefits, like easy support for different languages, security, etc.This is what we should definitely do! I would like to see our external interface being defined by means of AMQP 1.0 and message formats/exchanges.Some good resources on this topicIt’s great to have finally started moving things forward on this. I’m looking forward to hear your thoughts on the topics above.On Tue, Feb 23, 2016 at 10:25 AM, Henryk Konsek <hekonsek@xxxxxxxxx> wrote:Hi Kai,My #1 item now when I'm back from holidays is to dig into your initial contribution. :) I think that you can create GitHub issues from your points - I like those and we should work on them.As soon as I dig into Hono codebase more, I will be happy to pick some of those.Cheers!pon., 22.02.2016 o 11:36 użytkownik Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> napisał:Hi committers,
now that everybody has come back from vacations I think we should get started with doing some actual work on Hone, shouldn't we?
I would like to do a little brainstorming session in order to assemble a list of things we want to address first. We could then create issues in the GitHub repo for them, something like an informal backlog. I have already added an issue there and labeled it as "appropriate for new contributors" in order to point out that it would be suitable for people who do not have much experience with Hono's code base yet.
Here are some things I would like to address:
- implement an AMQP 1.0 interface for exchanging messages with clients
- add a REST interface for provisioning device identities and tenant information
- add support for Kafka as underlying messaging infrastructure
- provide a (simple) MQTT protocol adapter
What are your suggestions?
Mit freundlichen Grüßen/ Best regards
Kai Hudalla
Bosch Software Innovations GmbH
Schöneberger Ufer 89
10785 Berlin
GERMANY
www.bosch-si.de
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
_______________________________________________
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
--Henryk Konsek
_______________________________________________
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