[Libwebsockets] v2.0 coming very soon
thomas.spitz at hestia-france.com
Wed May 18 08:46:13 CEST 2016
I think I will use plugins however regarding lwsws I will rather not use it
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...
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 redirections,
> >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
> >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 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
> >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
> >future? I will certainly try to complete libwebsockets-test-server-v2.0
> 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
> >Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libwebsockets