Thanks MIchael, that helps. Any thoughts on moving to wolfmqqt with alias support? //.ichael On Tue, 13 Feb 2024 at 04:45, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
I think you'll find all our PRs/commits to Mongoose here: https://github.com/cesanta/mongoose/pull/894
I have no idea which have finally been merged or reimplemented by them, they more or less ignored us until their code base was too far off.
Regards, Michael
Am 11.02.24 um 09:58 schrieb Michael Geddes:
I've been looking at the work of Ludovic in updating OVMS to the new framework. I've even put up a few pull-requests where this work has uncovered bugs due to improvements in the compiler.
Ludovic did a great job in also updating the Mongoose library. For those unaware, the big issue is that there was a massive reworking of the library just after the point where ovms forked the library. I suspect some/many? of the changes that were made in our fork are no longer required.
There was a lot done in moving some of the work that had to be done in the callers (ovms) code into the mongoose code which is great - and Ludovic has done that conversion - there are just a few more things that needed to be done on top of that.
One of the things they did was remove mg_locals.h which allowed us to configure mongoose from our own custom include.
The other really annoying thing they did was to remove the use of MG_ALLOC, MG_CALLOC in place of malloc( calloc( etc. The problem with this is for freertos they define #define calloc(a, b) mg_calloc(a, b) #define free(a) vPortFree(a) #define malloc(a) pvPortMalloc(a) without any further condition. Tihs means we don't have a way of defining these to our own versions which is what we originally did... well not without forking the mongoose (which maybe we do anyway). It also means that any of our files that include mongoose.h will have these redefined away from our own versions of these. Fortunately it seems we don't use those much.
I also noticed that even the latest Mongoose MQTT doesn't appear to support aliases (and therefore optimising the amount of data used by a v3 server).. but it appears that wolfmqtt does - so should we be using that instead as a mqtt client??
Does anybody else have some further input on this??
//.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev