[hono-dev] Commands using the HTTP adapter

["Frank Karsten (INST/ECS4)" <Karsten.Frank2@xxxxxxxxxxxx>]

Hi all,

 

I like to shortly discuss the way we handle sending a command via HTTP back to a device.

 

We now have an almost merged solution for devices setting their "ttd" (time til disconnect) by adding an HTTP header

(or query param) to any downstream message.

The question is how the HTTP adapter itself treats the "ttd".

 

Scenario:

 

1.) the prototyped working version of the HTTP adapter delays the HTTP response by the number of seconds passed via "ttd"

to give an application the chance to send a command upstream

 

2.) an application receiving the downstream message evaluates the "ttd" and may or may not send a command (by using

the AMQP 1.0 link that was opened for the device)

 

3.) if there was a command, the HTTP adapter adds the command (received from the application) to the HTTP response and answers the HTTP request

4.) if there was no command, the HTTP adapter waits until "ttd" is expired and then answers the HTTP request

 

So far, so good.

 

 

The "problem" I like to discuss is that I have some concerns about the HTTP response delay:

 

Looking at step 3.) and 4.) and the expectation that commands are much less frequent than downstream messages, it would result in

 

3.) results in a quick answer

 

4.) results in a long delayed answer (will take the whole number of seconds that were specified by "ttd")

 

 

My feeling is we should have some information from the receiving application if there is NO command as well, not only if there IS a command.

 

 

Proposal:

 

To get a first version implemented we should nevertheless implement it like outlined above, and clearly emphasize this behaviour in the

documentation by giving some setup recommendations, like:

 

- devices rarely sending downstream messages may always set the "ttd" and live with the fact that the responses are most of the time delayed by this value

 

- devices often sending downstream messages should better use the introduced "empty event" to indicate every once in a while that they are ready for a command,

but NOT do this for every downstream message

 

- later we can search for a way to inform the adapter that there is NO command (or we find another solution)

 

All is only affecting the HTTP adapter (due to the request/response pattern).

 

Any opinions on that?

 

Thanks,

Karsten