mongoose as a thirdyparty package?

[Michael Glembotzki]

Hi Stefano,

shall we move mongoose outside of swupdate and link it dynamically to reduce the noice with every mongoose release? Only trouble is that often they introduce breaking changes and we have to update swupdate rev-id in such case in meta-swupdate as well.

I mean have an extra recipe like this: https://github.com/iris-GmbH/meta-iris-thirdparty/tree/master/recipes-core/mongoose

With yocto build's we are good to go then, but I dont know much about other setups (lokal host build, buildroot, debian package)? We might need official mongoose packages as well.

What do you think? Overkill?

Best regards,
Michael

[Stefano Babic]

Hi Michael,

On 4/28/26 12:13, Michael Glembotzki wrote:
> Hi Stefano,
>
> shall we move mongoose outside of swupdate and link it dynamically to
> reduce the noice with every mongoose release? Only trouble is that often
> they introduce breaking changes and we have to update swupdate rev-id in
> such case in meta-swupdate as well.
>
> I mean have an extra recipe like this: https://github.com/iris-GmbH/
> meta-iris-thirdparty/tree/master/recipes-core/mongoose
>

Theoretically I supposed to have support for multiple Webserver, and
there is a Kconfig to select the Webserver implementation. But on the
other side, users are already happy and nobody ask for a second source
or implementation.

The issue with the API does not change if we split the Webserver outside
SWUpdate. IMHO it could be worse, because we have then to provide
support for different version of mongoose and different APIs. At least,
at the moment, this is guaranteed by SWUpdate itself.

> With yocto build's we are good to go then,

Yocto is easier - we can also have a Kconfig that allows us to build
mongoose.c or to link a library. But I guess, we are not protected
against API changes.

I have also an additional issue due to license - according to Cesanta, I
can choose between commercial and GPL2.0 code. But this opens some side
effects if mongoose has a commercial license in a product and it is
linked to SWUpdate. The fact that license is established into the
imported mongoose's file drops any doubt.

> but I dont know much about
> other setups (lokal host build, buildroot, debian package)? We might
> need official mongoose packages as well.

Rather we need then debian package, and buildroot as well, and also
support for ISAR (this can be a debian package as well).

>
> What do you think? Overkill?

More than overkilling, it opens some other issues. So yes, packages for
not Yocto, and API consistence.

I take the chance to open for further Webservers (against). The main
point is to have a Webserver / library that does not break the streaming
feature. This is quite a challenge, as it is common for Webserver to
cache software. Mongoose was chosen for this reason, callbacks can be
set when stream is pushed. Civetweb (a mongoose fork) reuse the same
approach, API is nowadays (sigh !) different. Or create a generic
Webserver (maybe based on libevent) when SWUpdate is behind a proxy.

Best regards,
Stefano