[Libwebsockets] v2.0 coming very soon

Andy Green 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:
>Hello Andy,
>
>I think I will use plugins however regarding lwsws I will rather not
>use it

That'll get you most of the benefits.

>because my application need to computably  computationally (not
>manually)
>configure ports, redirect and protocols. Thus, I think going through
>JSON
>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.

-Andy

>Best regards,
>Thomas
>
>
>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
>>
>>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