[Libwebsockets] v2.0 coming very soon

Andy Green andy at warmcat.com
Tue May 17 20:48:29 CEST 2016



On May 18, 2016 1:43:04 AM GMT+08:00, Thomas Spitz <thomas.spitz at hestia-france.com> wrote:
>I think I will have to go for option 1 as you explained in
>https://libwebsockets.org/pipermail/libwebsockets/2016-April/002303.html
>in
>order to get an easy and maintainable solution for port redirections, 
>http
>processing, ...:

It's workable, but compared to just having a custom JSON config and a plugin, with everything else off the shelf, it's not the easiest or most maintainable way.

>1) Keep your existing code and attach your own mounts at vhost creation
>time
>
>https://github.com/warmcat/libwebsockets/blob/master/README.coding.md#using-lws-v2-vhosts
>
>Lws will serve the mounted contents automatically from where it's
>mounted
>in the server namespace
>
>Could you confirm that this solution requires libuv and or libev? I
>hope
>this will not stress too much my emdedded system ;-)

Plugins are what implies libuv (not libev).  However I think you find for Arm v7 running Linux, the idea libuv will 'strain' it is probably just prejudice.  Libuv is cheap as a crossplatform  wrapper around socket events or timers, and we're otherwise using it for crossplatform dirent and plugin operations at init.

Until recently when it got updated to a Rpi 3, libwebsockets.org was a 1GHz Armv7, before that a series of weaker Arm devices like CA8, even the weakest ones with 256MB would have had no trouble with libuv in the mix.

>I think this would have been nice to have cgitest, server-status in
>libwebsockets-test-server-v2.0 and libwebsockets-test-server to compare
>the
>three solutions (the third solution is lwsws).

The old test server code is bloated with adding support for the kitchen sink in there, making it difficult to use as the example it's intended to be; the advantage of the plugins + lwsws for maintainability is clear.

You can add everything in the plugins + lwsws JSON into test-server-v2.0.c as structs + protocols + api calls, but then it will become inflexible and huge... that's a big step backwards.

So the official test-server-v2.0.c should stay like it is, just having enough 'config by struct' to demonstrate the concept and leveraging the plugins, where a standalone server app is possible lwsws is the way to 'do everything' flexibly and maintainably.

>libwebsockets-test-server is
>probably not necessary as I assume it will be a depreciated solution in
>the
>future? I will certainly try to complete libwebsockets-test-server-v2.0
>tomorrow.

Yes the old all-in-one test server will continue to be supported (indeed the default, since everything else needs enabling at cmake).  But new stuff - I plan to discuss a completely new, highly abstracted protocol plugin project soon, and suitable third-party plugins could become provided as part of lws - will be provided as 'mix and matchable' standalone plugins only.

-Andy

>Best regards,
>Thomas




More information about the Libwebsockets mailing list