The logic for creating a shared_ptr for the active session
was flawed: it assumed that the session must be owned by
a client, which is not true if some other entity (like
a Connection) owns it.
As a result of this flaw, DBusServer::m_syncSession wasn't
set when running a sync via the Connection API, which
crashed when the Connection destructed itself and the
session while some of the session code was still active.
Fixed by keeping both a plain pointer (for the case when
the weak_ptr doesn't provide it anymore while shutting
itself down) and a weak_ptr (which avoids searching for
the shared_ptr).
This TransportAgent API revision was done in preparation for transport
agents which do not support HTTP. Forcing them to provide HTTP specific
methods is unnecessary, so now setting things like proxy is done when
constructing an HTTP-based agent in the createTransport() call.
So now the result of createTransport() must be ready for sending messages.
setURL() is still part of the API, because it provides message-specific
information. Perhaps it should be renamed when it is clearer what
the corresponding information in other transports is.
For connection oriented agents a new shutdown() call was introduced.
This gives them a chance to close the connection and inform the
engine about errors during that shutdown.
For servers (which send the last message without expecting a reply),
wait(noReply=true) was added.
The Session.Sync() parameters are a special case of temporarily
overriding the source properties of all or some sources. This
patch uses the new per-source config filters to transfer the
parameters to the core sync engine.
This patch also introduces Session members for temporary config
changes, which is another way of setting these and other parameters.
These Session members must be set in SetConfig(temporary=true) calls
(not done yet).
Selecting active sources during a sync or status check was done with a
combination of setting a sync mode via a source config filter and
setting a list of active sources. Now the SyncConfig supports a source
filter which is applied to all sources and source filters for each
source. The latter override the former.
This is powerful enough to start syncs with full control over which
sources are active in which mode, as described in the new D-Bus API.
As part of this patch, the command line semantic is implemented
entirely using a combination of different source filters.
The Session keeps the sync progress and status in the format expected
by the D-Bus interface. That way it is available without the corresponding
sync engine.
To run a sync, the Session.Sync() method creates a DBusSync, derived
from SyncContext. With an eye towards peer-to-peer sync the
new class and member are named just "sync" instead of using the too
specific "client". When that instance is ready, the g_main_loop_run()
call in DBusServer::run() is stopped and DBusServer::run() hands
over control to Session::run().
That call transfers control to SyncContext::sync(), which
retains control as long as the sync runs. Occassionally (via
progress calls) control is returned temporarily. These calls could be used
to check for D-Bus requests, but currently that is only done when
the sync blocks while transferring messages, by configuring the
SoupTransportAgent to use the same GMainLoop as the D-Bus binding.
The implementation of the D-Bus interface is still very much incomplete.
All of the missing bits and pieces are marked as TODO in the source.
This method complements the corresponding method in SyncSource.
At the moment it does not do more than calling the underlying
Exception::handle(). Calling it via SyncContext
is more natural and might be treated differently in the future.
Both methods are to be implemented inside the ReadOperations
class, which has the server configuration name as sole data item.
The Server methods are provided by glue code which instantiates
a ReadOperations object and calls the real methods.
From a C++ class design perspective the Server glue methods
should be declared static and the ReadOperations methods as const.
However, both qualifiers are not currently supported by the C++
binding.
This is basically a rewrite from scratch, targeting the revised D-Bus
API. The core infrastructure for handling client requests is in place,
including the work queue for sessions and unexpected disconnects.
Many of the related D-Bus methods (Server.Connect(),
Server.StartSession(), Connection.Close(), Session.Close()) are
implemented.
Rudimentary testing is done with the test/dbus-server-connect.py
script.
The new API defines two interfaces:
- org.syncevolution.Server for read-only access and starting sessions
- org.syncevolution.Session read/write operations and syncs
- org.syncevolution.Connection for transport stubs
At the moment the new D-Bus interface descriptions are purely for
documentation, they are not used by the GUI yet. Therefore syntax
errors might go unnoticed. Applying xslt to generate the docbook XML
catches some of these.
Members of structs must be read- and writeable
because the marshaling code accesses them directly.
The dbus_traits then can be defined by deriving
from dbus_struct_traits with template parameters
which describe the struct members.
With V being a basic type, "std::pair<size_t, const V *> &" can
be used to pass an array. The caller owns the array, so this
can be used for method parameters, reply parameters and signals,
but not for return values.
dbus_traits<V> must provide a dbus_type, which is used to
extract and encode the data efficiently via dbus_message_iter_get_fixed_array()
and dbus_message_iter_append_fixed_array().
Strictly speaking, an app has to use uint8_t when it wants
to exchange BYTEs with D-Bus. The extended binding maps both
int8_t and uint8_t to BYTE, so the app can use char and unsigned
char.
Use
const Caller_t &caller
to get a caller ID string. Caller_t is a class which mimicks a
string, which is necessary to distinguish this parameter
from a std::string parameter passed via D-Bus.
Use
const boost::shared_ptr<Watch> &watch
to be called with an active watch on the caller.
The callback invoked by the Watch must be set
with setCallback().
C++ classes and templates provided by header files simplify
programming in C++ with libdbus and libgdbus. libdbus items are
tracked with Boost shared pointers. Errors are turned into
exceptions. The binding to C++ is done via templates which provide the
C-style callbacks and declarations expected by libgdbus and map to
standard C++ types and STL data structures. Neither code generator nor
library code is required.
Synchronous and asynchronous method implementation are supported.
Asynchronous result deliver is done via a callback object with a
C++ signature that matches the values which have to be returned.
Due to the lack of variadic templates, lots of similar templates have
to be written to cover methods with varying combinations of arguments
and return codes. Not particularly elegant, but the alternative would
be to introduce a code generator, which has its own
drawbacks. Currently up to 10 items per method are supported, where
the number of items include the optional return value, arguments and
retvals.
Setting a Watch (base class) notifies the implementor of an when his
caller disconnects. This can be used to abort a long-running method
when the consumer of the result goes away.
Callers are identified by their unique Bus ID, represented as Caller_t,
an alias for a plain std::string.
Objects are represented by their path with a DBusObject_t, again a
plain std::string. By default, each path comes with one interface
(DBusObject). It is possible to instantiate multiple DBusObjects with
the same path, which appears on D-Bus as a single object with multiple
interfaces.
The DBusObjectHelper simplifies object handling. It stores the
necessary information and connection reference so that the object can
be unregistered when the DBusObjectHelper is destroyed. The intended
usage is that classes own instances of DBusObjectHelper and activate
those with a method table that points to class methods.
Signals are handled as instances of EmitSignalX templates where X
stands for the number of parameters, pretty much like ResultX
callbacks are handled. The function call operator emits the signal,
with the auxiliary information (D-Bus signal name) set when
instantiating the EmitSignalX object as part of a class. The D-Bus
connection and interface is provided at the time of the signal
emission by the parent DBusObject.
The table entry for the signal is created by a static member function
of the template, which allows building a static table as required by
gdbus. Note that the signal name must be passed into that
function. This slight duplication is necessary because the template
cannot be parameterized with a string constant. Turning
makeSignalEntry() into a normal member function would make it
difficult to build the signal table.
DBusErrorCXX is a helper class for DBusError which automatically
initializes the struct, can be used to check for an error and throws
an exception for it.
If the apps callback function removes the watch that
triggered it, then disconnect_function() used a dangling
data pointer to retrieve the id (first problem) and
g_dbus_remove_watch() used a -1 connection_slot (second
problem, only occurs when the current watch was the
last one).
Fixed by storing the ID in a temporary variable and
adding a connection_slot check to g_dbus_remove_watch(),
similar to the one which was already in g_dbus_remove_all_watches().
Apparently this was part of the design (there was a refcount
in ObjectData and a list of interfaces), but the implementation
didn't really use much of that.
Added a check whether there is already an object registered under
a path and reuse that object when adding further interfaces. Only
remove the object when its last interface is gone.
g_dbus_unregister_object() has the same logical flaw as g_dbus_remove_watch():
it left a dangling pointer to its data in the connection slot. This pointer
was found when the slot was reused in the following call sequence:
g_dbus_register_interface()
g_dbus_unregister_interface()
g_dbus_register_interface()
The result was a segfault.
The API had printf-style formatting for a detailed error description,
but that information was ignored. Added a sprintf variant which
allocates the resulting string dynamically, based on vsnprintf().
The library is compiled and installed as a syncevolution utility
library (in other words, as lib/syncevolution/libgdbus), so that
it never conflicts with a copy of the code in another project.
Without the remove call the matches would accumulate over time,
which can't be good for the dbus-server.
libgdbus commit ID:
d0084fd7b13b7f4665c223877f77576b08624dbf
g_dbus_remove_watch() decremented the slot ref count and freed
the ConnectionData associated with it if the ref count reached
zero. This left a dangling pointer to the ConnectionData instance
in the slot, which was found and used once the slot got recycled.
The new approach is to clear the data pointer in the slot if
its last user (watch or handler) is gone.
libgdbus commit ID:
3bb0e1e01230f50f66b3004ca385d73c49bff2c6
