Now I hope things are initialised in the right order and the plumbing
gets set up so that messages are passed as expected. It seems to work
most of the time.
Main changes are:
- The online WASM executable is built using the -s MODULARIZE -s
EXPORT_NAME=createOnlineModule options. This means that the WASM
runtime is not automatically initialized and the main() function
is not automatically started. Only when the createOnlineModule()
function is called is that done. Calling exported C/C++ functions
is a little bit more complicated.
- Code to actually Base64-encode strings to be executed as
JavaScript when expected is now present in wasmapp.cpp. (After
being passed through the Base64ToArrayBuffer function on the JS
side.) Whether this is actually necessary is not fully clear, but
to keep the code similar to that in the GTK, iOS, and Android
apps, this is kept as such for now. It would probably work fine to
just directly create the ArrayBuffer in the C++ (using the EM_ASM
magic).
- The COOLWSD::run() function is now run in a separate thread so
that main() can return.
- The FakeWebSocket's onopen() function is now called from
innerMain(), where the HULLO message is sent. It remains a bit
unclear if this really is the ideal place.
In the mobile apps the HULLO message is sent and the onopen()
function is called in the window.socket.onopen() function in
global.js.
But note that despite that the WASM app and the mobile apps are
largely quite similarly constructed and the FakeSocket and
FakeWebSocket plumbing is the same, there is an important
difference. In a mobile app the C++ code is what runs first, and
that then loads the HTML page into WebKit, in which the JS
runs. In the WASM app it is the other way around. The web page is
naturaly the one that is loaded and the JS code then starts
running the C++ code as WASM.
Finally, note that the whole concept that there is a separate "WASM
app" is temporary.
What we eventually want to achieve is that the COOL webpage upon
loading will connect a COOL server. As it does currently. The COOL
server runs the online and core C++ code to load a document, and
renders document tiles and sends those to the client JS code to
dispay.
The new thing will be that, if enabled, in addition to the HTML and JS
resources, the client will also download the WASM code and data
resources. Also, the document and updates to it will be downloaded
while being edited so that a copy can be kept in client memory. But
the WASM code and the downloaded document will remain unused most of
the time. Only if the connection to the COOL server breaks will the JS
start running the WASM code and the JS will talk to online code
running locally as WASM instead of to a COOL server. Obviously there
are still lots of things hanging in the air here regarding how exactly
this will work.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ib1786a0b485d51797b0f2302d4296aa1ff9df5c1
Just 4 is very likely not nearly enough. I think I did see some error
that could be related to running out of threads. Does
PTHREAD_POOL_SIZE limit how many threads can exist simultaneously?
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I5da637b5660e89655f7049b6754f70c74dff6da2
Also using soffice.data name instead online.data: online.js
looking for soffice.data
Signed-off-by: Balázs Varga (allotropia) <balazs.varga.extern@allotropia.de>
Change-Id: I62cee3f4866a2824a08b472f15bcdec06a6407b9
* add dependency on soffice.html.linkdeps to rebuild if core was rebuilt
* copy needed data files as-is from core build
* rename executable by setting automake EXEEXT var - appears to work
Signed-off-by: Michael Stahl <michael.stahl@allotropia.de>
Change-Id: I458b49290dae9d621a8043b1b3103d8b8fd606b8
The LO build directory in question needs to be one separately
configured for this (not one that would use Qt5 for UI, for instance),
so in the long run perhaps it does not make sense to create the FS
image there in core, but we should do it here in online? And we will
surely need additional files in the fs image anyway that core knows
nothing about.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I2cff0421da6075eefc017603ddf9d2ecf9dc79e2
-pthreads is required, or wasm-ld reports errors about
"was not compiled with 'atomics' or 'bulk-memory' features"
Also, POCO needs to be built with this, add it in README.
Signed-off-by: Michael Stahl <michael.stahl@allotropia.de>
Change-Id: Ie83e3942e5fc689e6df5a5a705d7ee2e1325ce03
Use the newly introduced soffice.html.linkdeps from core to get the
recursive dependencies into the link command.
This currently fails due to some problem with POCO:
wasm-ld: error: --shared-memory is disallowed by AtomicCounter.o because it was not compiled with 'atomics' or 'bulk-memory' features.
Signed-off-by: Michael Stahl <michael.stahl@allotropia.de>
Change-Id: I76b0a2265f67e89f6992d556525f1263ad1b45db
Copy the list of .cpp files from the Android project, assuming this will
be similar in scope.
Signed-off-by: Michael Stahl <michael.stahl@allotropia.de>
Change-Id: I57c7ad2f10d1867307ff4fcea3d0c650726d18d8
