[Extensibility] HTTP protocol

[DazWilkin]

Is your feature request related to a problem? Please describe.

A proposal.

Is your feature request related to a way you would like Akri extended? Please describe.

Part "can I repro 'Nessie'?".
Part "What could be even simpler?".

I'm noodling a handler based on HTTP:

• Device endpoints are discovered by GETting a URL from a separate discovery endpoint
• Devices are represented by an HTTP server with 2 paths: /health and /.
• The / returns a random number purporting as some sensor value; easily extended
• A companion app that creates an arbitrary number of "devices" and the discovery service using multiple ports on a default 0.0.0.0

Describe the solution you'd like

This solution is very basic but it's realistic (HTTP aside) of an MCU device with sensor(s) scenario.

Describe alternatives you've considered

The obvious alternative for MCUs would be to use MQTT and invert the flow of control: devices publish to broker, Akri subscribes to MQTT channels.

My sense (!) is that using MQTT doesn't extol Akri; I'm still unsure what the ideal use-case is for Akri but suspect that discovery and non-trivial interactions|data may be key (!?).

I considered using gRPC for device interaction but the added complexity appears to add no value in explaining Akri.

I considered using named pipes but feel this doesn't enlighten the developer and conveys locally attached producers.

Additional context

Plan to write the tutorial from-scratch.

[bfjelds]

This sounds very cool! 👍 👍 👍

[DazWilkin]

Super. Thanks.

Because of how embedded protocols are with Akri, I propose create a branch on my Akri fork for this?

Do you have a preference on how you'd like to receive PRs? In-flight development, commits as they happen with a final request to review? Or, would you prefer I keep it all out of your repo until it's ready and submit a PR then?

The (Golang) devices and discovery endpoint emulator is done

[kate-goldenring]

Hey @DazWilkin, I would say yes, definitely create a branch on your Akri fork for this. Then, when you have a working solution, throw us a PR.

[DazWilkin]

Awesome...

I appreciate all the support, @kate-goldenring

I'll push it tomorrow and ping you when it's there.

[DazWilkin]

For posterity, this is underway at: https://github.com/DazWilkin/akri/tree/protocol-http

[DazWilkin]

@kate-goldenring @bfjelds it's working besides my discovery DNS challenge in #102

[DazWilkin]

@kate-goldenring @bfjelds it's working now that #102 is addressed (thanks again @bfjelds)

Today, I added gRPC client and server in Rust and will test tomorrow. I'd previously written a Golang gRPC implementation but need to fix that now I understand how it should work.

Let me know if you're interested in a PR for any of the above?

I plan to blog about the experience too.

Thanks for all the help!

[DazWilkin]

You may prefer that this be its own branch as with Nessie?

[DazWilkin]

@bfjelds @kate-goldenring

Please let me know whether you'd like to finalize this or drop it.

I appreciate all your support and understand if this is no longer a priority.

[bfjelds]

Sorry @DazWilkin, we have been putting out some fires ... this is still a priority for us to get in! We have a goal of having someone walk through all of the steps and get it running this week. Other than any clarifications that come from that exercise, the remaining task will be to migrate the 2 md files (docs/extensibility-http.md & sample/apps/http-apps/README.md) in extensibility-http into the extensibility.md file in main (like extensibility.md does now: describing the changes made in nessie).

[DazWilkin]

Nothing to apologize for!

I'll move the Markdown files today.

[bfjelds]

http-extensibility branch has been created with reference code.

PR for changes to main extensblity.md has been created.