There is very little API guarantees about this, but clients seem to
expect *something* to work on a closed context. So split this up into
static info an more dynamic context-related info, but let's not
provide any guarantees about what keys are available when.
Fixes#599
A lot of work from @Hocuri and @Simon-Laux mostly.
This exposes the API of the deltachat-provider-overview crate on the
deltachat FFI API, allowing clients to use it to help users set up
their accounts.
This adopts the FFI API to use the new Context::new() and
Contest::drop() Rust-style APIs while preserving the semantics of the
existing FFI API. It introduces a wrapper around the context which
keeps an optional reference to the actual context, changing dc_open()
and dc_close() to create/destroy the actual reference.
This changes the events emitted on closing slightly: they only get
emitted when dc_close() was called while the context was open. While
dc_close() remains idempotent in that it can still be called safely
multiple times, the close events will only occur if the context is
actually closed.
A new context is now created by calling Context::new and therefore you
always have a valid context. This is much more in Rust style and will
allow a lot of furture simplifications on the context itself.
The FFI layer has not yet been adjusted in this commit and thus will
fail.
Adjust call sites as apporiate:
* src/dc_imex.rs(dc_continue_key_transfer): use if-let pattern
with dc_read_file_safe() and dc_msg_get_file()
* src/message.rs(dc_msg_get_setupcodebegin): ditto
* src/message.rs(dc_get_msg_info): simplify code to print information
about file inside a message.
* src/message.rs(dc_msg_get_file): simplify function using
dc_get_abs_path_safe()
* deltachat-ffi/src/lib.rs(dc_msg_get_file): convert PathBuf to `char *`
to preserve C API
The Message struct had a reference to the context which made a few
APIs a little easier. However it has surprising consequences a long
way down the line as shown in #335: it means any object which has such
a reference needs to keep open a lock if we want to do this refactor
of no longer having a "closed" Context struct on the Rust API (which
has many benefits which will simply that Context struct and is more
the Rust way - RAII etc).
By refactoring away the context reference on the rust API as done in
here however, we push this behaviour of how these references are
handled back to the C-API pointer behaviour: that is unsafe but just
works in a C-like way. The resulting complexity in the FFI layer is
also notably less than in the #335 alternative.
As a consequence all APIs which require the context, now explicitly
need to get the context passed in as an argument. It looks like this
is certainly no downside and maybe even beneficial for further API
refactors.
For this strategy to work out the same should be done to
dc_chatlist_t, dc_chat_t and dc_contact_t. But this working for
dc_msg_t give a reasonable confidence that this is a good approach.
Previously, logging macros (info! warn! error!) accepted integer
argument (data1), that was passed to callback function verbatim. In all
call sites this argument was 0.
With this change, that data1 argument is no longer part of macro
interface, 0 is always passed to callback in internals of these macros.
