Maybe we should add/include this recipe into the default/initial meta-subscriber-overrides.git, but not enable by default, and just refer to it from this doc. The same for main.cc, the doc could reference to the reference implementation in the code, https://github.com/foundriesio/aktualizr-lite/blob/master/examples/custom-client.cc.
In this case, there are more chances that the recipe and the code are in sync with the latest LmP and aklite ( for example, changes to the API won't require to change/adjust this doc).

I think this makes a lot of sense.

@mike-scott @ricardosalveti - any objects to including this skeleton type code in meta-subscriber-overrides?

Having it added by default is nice at first, but can also bit rot over time, as we won't update as we update factories to newer revisions.

Usually I prefer source code examples like this to be available via an external git repository, and only add the repo in SRC_URI instead. It is easier to manage, gets closer to what the developer would do anyway, and we can also keep it in sync with the factory version based on the SRCREV used.

If done purely as a sample and by consuming a public git repo that we host, we can even make it available in meta-lmp, and then make sure it gets tested / tagged as we push newer releases. Customers can then just copy the entire recipe and do their own when they get to create their own client.

k. Let me summarize what I think we are converging on:

clean up the example code

This change makes it easy to include in a recipe: foundriesio/aktualizr-lite#131 It also continues to be build tested in aklite

create a custom-sota-client recipe PR for meta-lmp

This will be cleaned up from the notes here. I guess the tricky part over time will be keeping the SRCREV here in sync/compatible with the SRCREV in aklite, but that was always going to be the challenge.

Does this make sense?

If we have at least one customer for the aklite API and there is an interest from other potential customers then I think it makes sense to include this recipe into the meta-lmp and make sure it gets tested (at least basic sanity test).

On the other hand SOTA_CLIENT overriding belongs to the meta-subsc as it's a factory customization. Maybe we just need to extend the test effort to make sure that each new LmP/meta-lmp release is tested in conjunction with the meta-subsc, effectively, emulate a new factory creation.

Yes, we can do that as we're already testing the release on a factory anyway. @mwasilew ^^

@rsalveti isn't @mike-sul asking for testing factory creation? AFAIK this isn't systematically tested yet (unless I'm missing something form @doanac's guys).