<div dir="ltr">Hello Andy,<div><br></div><div>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...</div><div><br></div><div>Best regards,</div><div>Thomas<br><div class="gmail_extra"><br>
<br><div class="gmail_quote">2016-05-17 20:48 GMT+02:00 Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On May 18, 2016 1:43:04 AM GMT+08:00, Thomas Spitz <<a href="mailto:thomas.spitz@hestia-france.com">thomas.spitz@hestia-france.com</a>> wrote:<br>
>I think I will have to go for option 1 as you explained in<br>
><a href="https://libwebsockets.org/pipermail/libwebsockets/2016-April/002303.html" rel="noreferrer" target="_blank">https://libwebsockets.org/pipermail/libwebsockets/2016-April/002303.html</a><br>
>in<br>
>order to get an easy and maintainable solution for port redirections,<br>
>http<br>
>processing, ...:<br>
<br>
</span>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.<br>
<span class=""><br>
>1) Keep your existing code and attach your own mounts at vhost creation<br>
>time<br>
><br>
><a href="https://github.com/warmcat/libwebsockets/blob/master/README.coding.md#using-lws-v2-vhosts" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/README.coding.md#using-lws-v2-vhosts</a><br>
><br>
>Lws will serve the mounted contents automatically from where it's<br>
>mounted<br>
>in the server namespace<br>
><br>
>Could you confirm that this solution requires libuv and or libev? I<br>
>hope<br>
>this will not stress too much my emdedded system ;-)<br>
<br>
</span>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.<br>
<br>
Until recently when it got updated to a Rpi 3, <a href="http://libwebsockets.org" rel="noreferrer" target="_blank">libwebsockets.org</a> 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.<br>
<span class=""><br>
>I think this would have been nice to have cgitest, server-status in<br>
>libwebsockets-test-server-v2.0 and libwebsockets-test-server to compare<br>
>the<br>
>three solutions (the third solution is lwsws).<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
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.<br>
<span class=""><br>
>libwebsockets-test-server is<br>
>probably not necessary as I assume it will be a depreciated solution in<br>
>the<br>
>future? I will certainly try to complete libwebsockets-test-server-v2.0<br>
>tomorrow.<br>
<br>
</span>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.<br>
<br>
-Andy<br>
<br>
>Best regards,<br>
>Thomas<br>
<br>
</blockquote></div><br></div></div></div>