Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Agenda for face-to-face meeting 
On 29/03/16 07:56, Kai wrote:

Here are some issues I would like to discuss during the meeting:

* Functional Scope - in particular, I would like to agree on some things
that will NOT be in scope (at least not from the beginning)
* Rough timeline - when do we want to release milestones, a 1.0 etc?
* Topology Options - as already started on the wiki page [1], I would
like to come to an agreement which option we start with
* Security/Privacy - I would like to make sure that we have a common
understanding of the basic guarantees Hono will give regarding data
privacy and how these should/could be enforced
* AMQP based API - we have started to work on the API for supporting
Telemetry data upload [2] which I would like to show to you and get your
feedback

We will probably not be able to cover sall topics in depth so let me
know what you think are the most important topics for which we should
reserve the most time.
Those issues all look valuable to discuss. From my point of view the overall aim is to try to clarify what Hono aims to be/do, especially in the short to medium term, and these different items on the agenda act as different ways of viewing that.
One suggestion: would it be worthwhile to spend a very short amount of time sketching out a simple use case or two to demonstrate the problem that Hono solves and/or help think about the scope in more concrete terms? 


I am currently in the middle of preparing everything for the meeting. We
will have two conference rooms to our disposal so we can also split up
into groups working on things in parallel if we see fit.
You will be able to use our WiFi to get internet access to VPN into your
company network to check emails etc.

Looking forward to seeing all of you in Berlin next week :-)

[1] https://github.com/eclipse/hono/wiki/Topology-Options
[2] https://github.com/eclipse/hono/wiki/Telemetry-API
I am perhaps jumping the gun a little here, but as time next week is short, posting some questions on the API drafts now may give people more time to mull over them.
* Should a given authenticated principal be able to access or sumbit data for multiple tenants? Should multiple different principals have access to the same tenant?
* In uploading telemetry data, the tenant-id is optional. If not provided how is that determined? Is a default assumed? Or is there some lookup of the tenant to which a device belongs? If the tenant *is* specified is there any verification that it matches the owner of the device?
* Depending on answers to the above, might the tenant be identified via a virtual hostname on the connection open?
* Is there likely to be a need to filter telemetry data for a given tenant in some way (by device, by device type or grouping, by logical subject etc)
* Might it be worth recommending use of the subject property on an AMQP message where appropriate. (E.g. an MQTT protocol adapter might use that to hold the original MQTT topic, a CoAP or REST adapter might use it to hold the resource identifier)? That then provides a basic uniform way to do logical classification.
* Would Hono store telemetry data for any length of time independent of any active subscribers?
* The content-type is described as 'MUST be set to application/octet-stream if content is to be considered opaque binary data.'. How would the receiver know how to decode that? Would they infer it from the device-id? Or would that be 'application specific'? Is the intent of that description to discourage more explicit content-types?
* On a related point, I would imagine that some solutions would benefit from not having to map/convert between different data formats themselves, but to see data from different devices in some uniform format/model. Do you see some form of canonicalisation and/or conversion of data to be in or out of scope?
* On a very pedantic point, the target and source addresses for telemetry producers and consumers respectively is defined to include 'telemetry/upload'. Is there any other category of telemetry data being considered, or is the upload perhaps redundant?

Back to the top