search

golioth / zephyr-asp

Zephyr application support packages
Apache License 2.0
0 stars 0 forks source link

Explore moving our wi-fi helper out of zsdk to here #1

Open 0Grit opened 2 years ago

0Grit commented 2 years ago

There are useful bits of code we will create that have nothing to do with Golioth.

I'd like to share these here.

First thing that crossed my mind was the Wi-Fi logic we have built into our zephyr-dsdk. As a first exercise I'd like to see what it would take to move that logic here.

0Grit commented 2 years ago

@golioth/firmware

0Grit commented 2 years ago

@vitprajzler vision for this repository is to capture any useful generic zephyr dependent code we develop as a byproduct of developing Golioth device service clients.

mniestroj commented 2 years ago

I'd rather put "any useful generic zephyr dependent code we develop as a byproduct of developing Golioth device service clients" into separate directory, but directly in zephyr-sdk repository. Less repositories means less dependency/compatibility management between them.

WiFi service in general is something that Zephyr needs to include at some point, so hopefully we could contribute/develop it directly in Zephyr or use it as is once somebody else develops it.

0Grit commented 2 years ago

Even if it's just the one external dependency? It is only our samples that rely on it correct?

vitprajzler commented 2 years ago

Sorry, but from the description I don't understand why this repo is needed. What specific problem that we have right now is this addressing?

0Grit commented 2 years ago

It would clarify what pieces of our SDK are part of the SDK versus which are scaffolding for examples. It would also promote reuse of said scaffolding by other applications and our users.

That separation could be defined more clearly within our SDK I suppose, but I personally prefer libraries arrive into my project in small succinct pieces.

It sounds like the question will be how much actual human overhead would there be to manage this code as a dependency of the samples within our SDK.

vitprajzler commented 2 years ago

In the scope of recent discussions, I believe this is not a priority right now.

We can revisit it once it becomes a blocker to developer experience with the SDK.