Kai Hudalla
Kai Hudalla
Hi, I really like your theme and I would like to use it for the Eclipse Hono project's website. However, in order to do so, the Eclipse folks will need...
This test case tries to reproduce the problem described in #94. It is not meant to be merged but is supposed to illustrate the issue and serve as a basis...
The 1.36 release's collector component supports the OTLP protocol natively, i.e. there is no need for a dedicated OTEL collector component that forwards to the Jaeger back end anymore.
The command line client is currently built and distributed as an *uber-jar* which requires a locally installed JVM to be run. Quarkus already allows us to create a native executable...
The container images created for the Hono components currently run on x86_64 architectures only. In order to take advantage of cloud providers' offerings around arm64 based hardware (which often is...
The [CloudEvents](https://cloudevents.io/) spec describes a set of standard (meta data) properties and transport protocol bindings which are used to allow compatible applications to recognize and process such events in a...
Vert.x [4.2 introduced support for MQTT 5](https://vertx.io/blog/whats-new-in-vert-x-4-2/) on the server side. Would be nice to support it in the MQTT adapter.
The protocol adapters currently use the *issuer DN* from the device's end-entity certificate to look up the tenant that the device belongs to. Let's assume a chain of trust as...
The devices connecting to Hono usually only provide credentials for authenticating with a protocol adapter. Hono currently does not maintain information about the devices' type, make, model and/or capabilities. That...
Currently, components authenticate each other based on SASL PLAIN. However, under the hood, the server components forward the credentials provided by the client to Hono Auth in order to retrieve...