[Libwebsockets] recent changes breaking DomTerm

Per Bothner per at bothner.com
Tue Jan 23 07:32:01 CET 2018

Rather belatedly I updated my libwebsockets check-out (motivated
by trying to build DomTerm on Ubuntu) and I ran into a number of problems,
which I don't have a full handle on.

(1) This change:
     commit 5b74d7108b5cfcc3a6ee3dcad521e0f0c3a18d0c
     Date:   Tue Nov 14 11:25:54 2017 +0800
changed the LWS_WITH_ZIP_FOPS default.  This took me a while to
figure out, party because it was confounded by other issues (see below).

Some questions (I apologize if I missed some discussion on the list):

(a) Why did the default change?  Of course "to reduce library size"
is a perfectly reasonable answer, but I want to understand if there are other reasons.

(b) I'm concerned that if the default changed, people who distribute
compiled libwebsockets might stick with the default, which might complicate
building DomTerm using a system libwebsockets package.

(c) Is there a cpp conditional I can check to see if LWS_WITH_ZIP_FOPS are enabled?
I don't *have* to have LWS_WITH_ZIP_FOPS enabled, but I need to be able to
check if it is, preferable in DomTerm's configure script.

(2) Once I re-built libwebsockets with -DLWS_WITH_ZIP_FOPS=1 things
work for the 5b74d7108b5cfcc3a6ee3dcad521e0f0c3a18d0c, but things break
again two commits later:

     commit df46d8827cc3c1ffd60ea5524b1074c014cd304b
     Date:   Thu Nov 16 11:26:00 2017 +0800

I haven't tried to track down how this caused DomTerm to break.

(3) DomTerm doesn't require LWS_WITH_ZIP_FOPS to be enabled.  Instead,
if you configure it --enable-compiled-in-resources then it serves the
needed JavaScript+CSS  directly from initialized static byte arrays.
This works fine [*] until we get to:

     commit 1da0197798c3c19e5b60dd0e47b1724f08ce56de
     Date:   Thu Dec 7 07:20:47 2017 +0800

which breaks the --enable-compiled-in-resources (non-zip-fops) version
as well.   So now I'm screwed.

I haven't studied the Dec 7 commit to see how it breaks DomTerm, as it
a another fairly complicated change.  (I wanted to summarize my
results-so-far before going to bed.)

[*] A disadvantage of --emable-compiled-in-resources if we also want to
provide a "pure-Java" version of DomTerm, since that needs to get the
JavaScript+CSS from a jar file.  Being able to use the same .jar file for
both the Java version and the C (libwebsockets) server is elegant and
saves space, but is not essential.
	--Per Bothner
per at bothner.com   http://per.bothner.com/

More information about the Libwebsockets mailing list