A quite common logic that is best moved to a utility
and optimized for best performance.
Includes unit-tests.
Change-Id: Id63a388690c17355eb2fac529070c38e9b082fd0
This is needed so we can use this inside ChildSession.
Change-Id: I88f2cc767412fd52dbb242938f0f9897d4277639
Reviewed-on: https://gerrit.libreoffice.org/63836
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Add an entry to discovery.xml with the urlsrc where capabilities end
point can be found. Use json format to send back the feature list.
Change-Id: I390a53d956d53ca79e5a8090aead7f4131ec4ca0
Also support anonymization of downloadas documents
and renaming of documents.
Reviewed-on: https://gerrit.libreoffice.org/57541
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 78248a542c9ca31bf9ad4cad9b55d78690384395)
Change-Id: I81a80e6290217659987d73f625e5f0fb81cb7ef2
This is important for when we abort with some explanation.
Often said explanation doesn't show up anywhere to be useful.
Also, issue fatal logs for abnormal exist and use SFL to log errno.
Reviewed-on: https://gerrit.libreoffice.org/57540
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit ad7964393eadb68873b820e0a620fb40f1e1b06a)
Change-Id: Ic67064ef40ef6e93d26e5847ecd32bdd49c3cc8b
The async-signal-safe functions to get thread-id
and thread-name, which cache the results, are
faster, cleaner, and signal-safe. No reason why
we shouldn't always use them.
Especially since it appears the logic was
inverted in Log::prefix, such that the signal
un-safe calls were made during signal-handling,
and the safe ones were called otherwise!
Instead of passing the signal-safe flag to
Log::prefix, we pass the buffer size, for
improved security.
Furthermore, reduce header dependencies
and reduce clutter.
Change-Id: I697689b2f0a290b6d8cce4babc3ac1e576141da6
The idea is that it would work sufficiently identically, so that even
people without a Mac and without an iOS device could participate in
development of the non-iOS-specific bits, like the JavaScript, or the
online MOBILEAPP-specific plumbing. Which would be great.
No, this doesn't do anything sane yet. It does compile the same online
C++ files as the iOS app, though. (Some minor tweaks were needed in a
couple of them to silence gcc warnings.)
There is a plain Makefile, but I should change to using autofoo, too.
Eventually, this will need to be built in a separate tree from a
normal online, just like when using the --enable-iosapp configure
switch. (But for now, doesn't matter.)
Change-Id: I13e4d921acb99d802d2f9da4b0df4a237ca60ad6
We don't have any user-generated signals to handle by shutting down in
an app.
One less thing to worry about. Now it's just the global
TerminationFlag that is problematic when the code runs in just one
process.
We try to decrease the network usage with avoiding sending out
to much tiles to the client. When we already sent out two versions
of the same tile without having the tileprocessed message from the
client we delay sending out the next version to avoid spamming tiles
on the network.
Change-Id: Ia47cd7c0d3fb829f6777f0c3265970433591df19
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
The app is unimaginatively called "Mobile" for now.
Runs but crashes pretty quickly after loading the document by the LO
core. Will need some heavy changes to get a ClientSession object
created in there, too, to handle the (emulated) WebSocket messages
from the JavaScript. It would then handle some of these messages
itself, and forwards some to the ChildSession, which in this case is
in the same process. Now the messsages from the JavaScript go to a
ChildSession, which is wrong. As the assertion says, "Tile traffic
should go through the DocumentBroker-LoKit WS"
Re-think Linux vs mobile ifdefs a bit. Use #ifdef __linux only to
surround code that actually is Linux-specific. Use #ifdef MOBILEAPP
for code that is for a mobile version (with no separste wsd, forkit,
and kit processes, and with no WebSocket protocol used).
Bypass UnitFoo for mobile. Possibly we do want the UnitFoo stuff after
all on mobile, to run in some special testing mode? Hard to say, let's
skipt it for now.
