We don't check if boost is available in the configure phase so we
can't use it. It is possible to add it but as we only use it in
one place and it is actually not really needed, it is better to
remove the usage.
This change also moves the std::list to std::deque.
Change-Id: I4c661a2fb8995bf756a0815a6e30bb304f22d3c8
Reviewed-on: https://gerrit.libreoffice.org/58640
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This reverts commit f1a385be98.
It's not easy, it can interfere the tile tracking.
Change-Id: I1e4ec9b4d66e5e912873f673fd5cb71ba55a9332
Reviewed-on: https://gerrit.libreoffice.org/59326
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
No need to keep such a cache here. The consumer of previews
(thumbnails) in question does it itself (Nextcloud).
This reverts commit 405b66c8db
Change-Id: Iad16212ccbc875fe4f6d041e2fceef7eaea1d1bb
Store the tile cache names and drop outdated tiles
times to times, so we can avoid tile rendering / sending to
stuck.
Change-Id: Ibff001307c7c660cbc57ab20c29c430e0090444d
SenderQueue might drop some tiles, so we were waiting for
tileprocessed message for a tile which was not sent at all.
Change-Id: I7c502966f656e46df7c22002dee19aeabbf97774
I used number 25 as this limit. It's an approximate value. It's enough
to handle the first 5-10 character input without waiting for tileprocessed
messages. After the first 5-10 characters the tileprocessed messages are
arriving continuously (same frequency as the typing speed), so for the later
character inputs we always have some tileprocessed messages arrived so
we can push new tiles to the network again.
This 25 upper limit also seems enough to send all tiles when a whole page is
requested (e.g. zoom os scroll).
We store the requested tiles in a list, used as a queue. I don't use std::queue
because sometimes we need to do deduplication (replace older versions of the
same tile with a newer version).
Change-Id: I22ff3e35c8ded6001c7fc160abdc1f1b12ce3bae
We always one bunch of tiles (e.g. all tiles invalidated) and we
are waiting until client send tileprocessed message back for all
tiles before sending the new tiles.
By canceltiles message we drop every previously requested tiles and
make wsd ready to send new tiles, which will be requested by the client
in theory.
Change-Id: I9901420ada549e962ffaf5e6bd58e52b86bd129d
When asked to "convert" a document to a PNG image, i.e. what one can
call a thumbnail, check if we have a cached PNG for the same docuemnt
already, and in that case return it.
When we have done such a convert-to operation to PNG, save the result
in the cache for later re-use.
This change adds no thumbnail cache cleanup mechanism. That will have
to be implemented separately using a cron job or whatever.
There are further improvement possibilities: For instance, if the
document is of a type that contains an embedded thumbnail (like ODF),
just extract and return that. For ODF that embedded thumbnail even
already is in PNG format.
Change-Id: I882efe97acc1d81041dc7a4ccb222995940e4836
Reviewed-on: https://gerrit.libreoffice.org/57345
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
userextrainfo is a json array that contains
extra user-specific links.
Currently 'avatar' is assumed to hold the
image url for the user's avatar.
'mail' and other links can also be added.
Change-Id: I37c4c68bfa0b7ee659e017b4867dcb8cf5c2ca2f
Reviewed-on: https://gerrit.libreoffice.org/38120
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
...but in combination with the appropriate session's access_token to always
authenticate against the same instance of the WOPI host.
Change-Id: Ic94dfa8fcb226a2d134272b22edc1f8f76c24e34
Dung out overlapping return enumerations. Move more work into 'move'
callbacks at a safer time, etc.
Change-Id: I62ba5a35f12073b7b9c8de4674be9dae519a8aca
Not to confuse with the DocumentBroker isLoaded,
this is view-specific. Except for the first view,
which is identical to the document being loaded,
subsequent view loadings are independent from,
though follow, document loading.
Change-Id: I0f21016fa84bf507ca4bc0e7a6c7d0d76b033c60
Reviewed-on: https://gerrit.libreoffice.org/36761
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
If a session is not loaded, it might never
do so. We should skip them when deciding
whether to save using a disconnecting
session or rely on another.
This is to avoid failing to save when
the remaining sessions never really load
the document at all, and are therefore useless.
Change-Id: I4e7127e12960a31e9f66e835bb63fb2347390711
Reviewed-on: https://gerrit.libreoffice.org/36710
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
assert()'s are no-op in the release builds, but we still want to see threading
problems in the log at least.
Change-Id: Idb02bb018e8f2d628a57ab570249613ad00bcff2
With this every other client would be able to know about other client's
permission i.e whether they have opened the document as readonly. This
could be important eg: to hide the cursor overlay of readonly users in
the UI or to mark these users as readonly in the userlist.
Change-Id: I5dcb1b4e5a22c9b546d16b69b9216cc7653cff04
Since this doesn't necessary mean the document
was loaded completely (as the similarly named
flag in DocumentBroker signifies) rather that
the session was added to DocumentBroker.
Change-Id: Ibfc702bbd111ade2715dcb28ac3aa4e9e8e025dd
Sessions are now added to the DocBroker
_sessions map and loaded from the poll
thread first before processing their
messages.
Since messages are not read from the
sockets outside of the poll thread,
there is no reason to queue them
at all. The only exception is when
messages are passed directly
to ClientSession during convert-to
requests. That will be handled
separately (for now convert-to test
fails).
Change-Id: I798166b9e45b5707a33d31137e01a32ce63630b1
Reviewed-on: https://gerrit.libreoffice.org/35705
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Once a socket has changed ownership to a new
poll it will assert thread affinity with said
new poll. So we cannot do any IO on the old
poll's thread at that point and on.
Change-Id: I662f188dea7c377a18f3e546839ec43f2875dc7b
While message emplacement happens in the DocumentBroker poll, we
can be sure that the next iteration of the poll will call
hasQueuedWrites before polling.
