[Libwebsockets] recent changes breaking DomTerm
andy at warmcat.com
Sat Jan 27 01:23:31 CET 2018
On 27/01/18 02:52, Per Bothner wrote:
> DomTerm trunk now works with libwebsockets trunk. Yeah! I fixed
> any regressions that I noticed so far, but I will continue testing.
> Thanks for you help.
Great. The back-to-back stuff (now it covers RAW properly...) is lws
being more proactive in enforcing restrictions that already existed, but
that you could usually get away with. So although it's a bit painful,
the result will be solid against different kinds of network link and
>>> (b) I'm concerned that if the default changed, people who distribute
>>> compiled libwebsockets might stick with the default, which might
>>> building DomTerm using a system libwebsockets package.
>> Yeah. It's a reasonable concern.
>> Lwsws should also be on by default in packaging. There are lots of
>> other features like ACME support now in master that should be on.
> Would it make sense to have a cmake option that that turns on
> LWS_WITH_ZIP_FOPS and other options that are recommended/suggested for
> library packagers?
> Something like LWS_PACKAGE_DEFAULTS or LWS_PACKAGING_RECOMMENDED?
> This could be mentioned in READMEs/README.build.md
Yes it's a great idea, thanks. I pushed a patch adding an
LWS_WITH_DISTRO_RECOMMENDED=1, note in READMEs/README.build.md and
updated the example rpm specfile to use it.
> One might argue that LWS_PACKAGE_DEFAULTS=1 *might* be a reasonable
> assuming most people are running machines with plenty of memory, and the
> people running on more constrained systems will probably have to customize
> their build for their specific needs anyway.
Well, people won't use features that were default-enabled but they don't
know about them.
And although for PC case it's reasonable, many people gravitated to lws
because they have weak / restricted platforms, or integrate it in
something else; the weakest platform we support atm is ESP32.
So what I ended up with is wanting the test apps to work out the box,
anything not needed for that is optional. CMakeLists.txt is reformatted
a few months ago with the options in sections so it's easy to see what's
> Are people running "small" systems generally using static libraries?
If it's "small" but Linux, usually they have multiple executables in
their rootfs and are using dynamic libs. Static only makes sense if you
basically have one app in the system; if you have many apps up that
depend on eg, libssl, with dynamic link there is only one copy usually
of libssl in physical memory no matter how many apps are running that
use it. With static linking, n apps that have libssl.a have the
corresponding footprint in physical memory for each instance's paged-in
parts separately, since they no longer resolve to a common lib, it's
worse if n > 1.
Of course there can be overriding considerations, static link is useful
is you want the thing to unconditionally work even if the rest of the
rootfs is missing etc.
> If so, that provides a way for them to "automatically" only link in
> what they need - assuming the library avoids static cross-module
Yes the ESP32 stuff is using function-level linking to get that behaviour.
However a lot of the cmake options have implications, eg allowing for
extensions changes the sizes of various structs and creates additional
calls in various places just in case there's an active extension.
Function-level linking doesn't remove this overhead.
Enabling everything brings in additional libraries... on the basis
people may be unaware of the feature if on by default, and get no
benefit, this is bloat effectively. For permessage-deflate extension,
that also has implications for runtime CPU and memory on both client and
server side, but if it exists browsers will negotiate it; having it on
by default unknown by the developer may be exactly what he doesn't want.
At least if he goes in and enables it, he knows it exists and he chose
to have it on.
For distro use, enabling most things makes sense because they can't
predict what the user may want from it and then covering all the bases
is the way to go... and it's pretty cheap on a PC type system. If they
wanted to optimize their system completely there are many ways using a
generic distro goes against that, not least glibc itself.
More information about the Libwebsockets