This move the defaulting to IdNameMapper in the configuration instead of
in the InternalServer.
This also create a default shared_ptr per Configuration instead of
using a static default one.
While it was "ok" to store raw pointer as, in our use case, the nameMapper
always live longer than object using it; it is not safe to store
raw pointer on object than may be deleted.
All classes storing a NameMapper now store a shared_ptr.
Functions only using the library (as `HumanReadableNameMapper`) continue
to use a (const) reference.
While it was "ok" to store raw pointer as, in our use case, the library
always live longer than object using it; it is not safe to store
raw pointer on object than may be deleted.
All classes storing a library now store a shared_ptr.
Functionr only using the library (as `HumanReadableNameMapper`) continue
to use a (const) reference.
It is used to store the server configuration instead of passing (a lot of)
arguments to functions/creators.
Please note that this remove the thread protected on m_verbose.
m_verbose is initialized once and never modified, be don't need to protect
access.
If we keep a reference to a `Reader` it is better to (share) owning
the reference. Else the reader may be deleted after we create the searcher.
This is especially the case now we are creating the `Reader` at demand
and we don't store it in the library's cache.
We have to reuse the query the user give us to generate the
pagination links.
At search result rendering step we don't have access to the query object.
The best place to know which arguments are used to select books
(and so which arguments to keep in the pagination links) is when we
parse the query to select books.
Fix tests (pagination links) with book selector other than "books.id="
(pattern=jazz&books.query.lang=eng)
libzim's search is not thread safe (mainly because xapian is not).
So we must protect our search objects from multi thread calls.
The best way to do this is to associate a mutex to the `zim::Searcher`
and lock the searcher each time we access object derivated from the
searcher (search, results, iterator, ...)
As we still create a `Reader` in the deprecated code of `Library`,
we need a way to create a reader without raising a deprecated warning.
So we create a another constructor with a dummy argument and we use it.
As the `Entry` is still created by `Reader` we need a way to create a
entry without raising a deprecated warning.
To do so we create a second constructor with a dummy argument.
This second constructor is private and is not marked as deprecated so we
can use it.
kiwix::fileExists only checks for file existence now
kiwix::fileReadable will check if the file is readable (implicitly checking for file existence also)
Library became thread-safe with the exception of `getBookById()`
and `getBookByPath()` methods - thread safety in those accessors is
rendered meaningless by their return type (they return a reference
to a book which can be removed any time later by another thread).
Introducing a mutex in `Library` necessitates manually implementing the
move constructor and assignment operator. It's better to still delegate
that work to the compiler to eliminate any possibility of bugs when new
data members are added to `Library`. The trick is to move the data into
an auxiliary class `LibraryBase` and derive `Library` from it.
Originally `LibraryManipulator` was an abstract class completely decoupled
from `Library`. Its `addBookToLibrary()` and `addBookmarkToLibrary()`
methods could be defined in an arbitrary way. Now `LibraryManipulator` has to be
bound to a library object, those methods are no longer virtual, they always
update the library and allow for some additional actions via virtual
functions `bookWasAddedToLibrary()` and `bookmarkWasAddedToLibrary()`.
Matthieu Gautier
Nikhil Tanwar
Emmanuel Engelhart
Tristan Havelick
Veloman Yunkan