[Libwebsockets] v2.0 coming very soon
andy at warmcat.com
Wed May 18 09:06:19 CEST 2016
On May 18, 2016 2:46:13 PM GMT+08:00, Thomas Spitz <thomas.spitz at hestia-france.com> wrote:
>I think I will use plugins however regarding lwsws I will rather not
That'll get you most of the benefits.
>because my application need to computably computationally (not
>configure ports, redirect and protocols. Thus, I think going through
>files will certainly be more complex than dealing with native C
>structures... I might be wrong...
You know your application better than I do... if it's easier to wire up with structs, no problem.
One observation though... JSON is easy to machine-generate if need be.
>2016-05-17 20:48 GMT+02:00 Andy Green <andy at warmcat.com>:
>> 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
>> >order to get an easy and maintainable solution for port
>> >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
>> maintainable way.
>> >1) Keep your existing code and attach your own mounts at vhost
>> >Lws will serve the mounted contents automatically from where it's
>> >in the server namespace
>> >Could you confirm that this solution requires libuv and or libev? I
>> >this will not stress too much my emdedded system ;-)
>> Plugins are what implies libuv (not libev). However I think you find
>> Arm v7 running Linux, the idea libuv will 'strain' it is probably
>> prejudice. Libuv is cheap as a crossplatform wrapper around socket
>> or timers, and we're otherwise using it for crossplatform dirent and
>> operations at init.
>> Until recently when it got updated to a Rpi 3, libwebsockets.org was
>> 1GHz Armv7, before that a series of weaker Arm devices like CA8, even
>> weakest ones with 256MB would have had no trouble with libuv in the
>> >I think this would have been nice to have cgitest, server-status in
>> >libwebsockets-test-server-v2.0 and libwebsockets-test-server to
>> >three solutions (the third solution is lwsws).
>> The old test server code is bloated with adding support for the
>> sink in there, making it difficult to use as the example it's
>> be; the advantage of the plugins + lwsws for maintainability is
>> You can add everything in the plugins + lwsws JSON into
>> as structs + protocols + api calls, but then it will become
>> huge... that's a big step backwards.
>> So the official test-server-v2.0.c should stay like it is, just
>> enough 'config by struct' to demonstrate the concept and leveraging
>> plugins, where a standalone server app is possible lwsws is the way
>> everything' flexibly and maintainably.
>> >libwebsockets-test-server is
>> >probably not necessary as I assume it will be a depreciated solution
>> >future? I will certainly try to complete
>> Yes the old all-in-one test server will continue to be supported
>> the default, since everything else needs enabling at cmake). But new
>> - I plan to discuss a completely new, highly abstracted protocol
>> project soon, and suitable third-party plugins could become provided
>> part of lws - will be provided as 'mix and matchable' standalone
>> >Best regards,
More information about the Libwebsockets