The new method is needed for importing item data from stdin, a new
feature for the command line. The default implementation which is
used when executing the command line locally reads from std::cin
directly.
The syncevo-dbus-server would have to ask its client for the data;
this hasn't been implemented yet. To catch the problem and inform
the user, an exception is thrown there.
If (and only if) compiled with --enable-evolution-compatibility (as
the binaries on syncevolution.org), libical was only pulled into the
syncevo-dbus-server as part of running a sync. That was too late for
libsynthesis, which had already checked for libical earlier in that
sync session.
All following sync sessions then used libical time zone information.
The effect of not having libical time zone information were occasional
mismatches of time zones.
When logdir can't be accessed, SyncContext handles the error and returns
an error status and command line only returns a false flag. So D-Bus
server has to handle the 'false' flag and throws an exception to
indicate this error to clients.
mutter-moblin automatically adds that button itself. Because it didn't
recognize that we also add it ourselves, we ended up with two buttons
called "Dismiss".
The way to avoid this and having a "Dismiss" button in other environments
is to use the ID "default" for our "Dismiss" button, then it'll be ignored
by mutter-moblin.
When running command line arguments in dbus server, it is necessary
to pass environment variables in the command line environment.
The temporary solution is just to collect possible used environment
variables to dbus server. To support it, a new argument of dbus
method 'Session.execute' is added to pass the map of environment
variables.
If there is any error during executing command line arguments in
dbus server, it should catch the exception and set the error code
in the Status. Thus command line can judge the error code and
return the correct value to system.
When user didn't provide password, sync ui sends a hash without
'password' key-value pair in the response. Abort the current sync
process under this situation.
When passwords in the config are not set, the daemon asks them from
clients like command line. Command line should react and let
user input passwords and then send responses to the daemon.
Command line listens to 'Server.InfoRequest' signal and only handles
password requests from sessions created for command line in the daemon.
If command line dies in the process of inputting passwords, the daemon
always waits for it so expand current timeout mechanism into this
process. Otherwise, the daemon waits permanently.
Previously it is supposed the arguments passed to d-bus are valid.
This seems not good as there are always some unpredictable issues.
Throw exceptions when parsing them encoutering errors.
When getting config of a template in a context, configs in the
context are applied in the returned configs except 'type' property
of sources. 'type' property should be preserved from the template.
It's a special case.
A client which wants to create a new config in a non-default context should
always use
config = GetConfig("<template>@context", true)
<make changes>
SetConfig(config)
to ensure that shared properties in that context are preserved.
A client shouldn't have to check whether that context exists. If it doesn't,
the server should simply ignore the context and use the default values from the
template.
This patch adds a test for this, based on the "type" property. The expectation
in the test that the "type" is preserved literally is wrong. "type" currently
must not be preserved, because different templates may have to set
different data formats (MB #10443).
syncevo-dbus-server is the first usage of LogRedirect which also
redirects stdout. In turn, the main usage is catching of "synccompare"
output. It turns out that the assumption for stderr so far that writes
are atomic doesn't hold for stdout of synccompare. Lines often are
interrupted in the middle.
In addition, SE_LOG(SHOW) always inserts a newline.
This patch deals with this by treating data received for stdout as a
data stream. It buffers incomplete lines and appends the rest of the
line when the next chunk comes in.
This delays printing such an incomplete line. flush() is introduced
to get that last, incomplete line logged.
For stderr, keeping text in memory instead of printing it as soon
as received is considered undesirable, therefore that code path
is not changed.
Redirection of stdout was not activated and thus output of
synccompare was not sent via LogOutput messages.
Activating it shows that more work is necessary, although
it works in principle. Problems: line breaks are inserted
into long synccompare output and lines are swallowed.
Also, cout should not be used by the server itself. Instead
use the logging facilities.
The recent patch which moves setTransportCallback() into
createTransportAgent() as incomplete, it didn't adapt
DBusSync::createTransportAgent().
As a reminder, this patch also updates the createTransportAgent()
comments.
Previously, plain strings were used. With DBusObject instead
the C++ bridge code recognizes the special meaning of those
and correctly sends them over D-Bus as object paths.
Exceptions thrown inside Cmdline::run() were reported after leaving
and destructing CmdlineWrapper, and thus never reached the client
because that's what CmdlineWrapper does.
Fixed by adding a try/catch block in CmdlineWrapper::run().
This patch started with the goal of changing the uint level into
a string. The motivation for that was that the numeric constants
would have to be documented (which they weren't) and prevent
us from easily changing the Logger::Level later on.
I did change them once today (see previous commit about reordering the
SHOW level) and really had the problem that a not-restarted
syncevo-dbus-server couldn't talk to a recompiled client.
Using strings avoids that problem.
While changing uint to string I had to make the change twice, once in
an entirely unnecessary new and the pointer definition. Replaced the
shared_ptr with normal members, throughout the code.
Then I wondered about the use of the () operator on these signal
watches. At the point of use it was not obvious what that did. Turns
out that this activates the watch. In contrast to making a remote
function call or emitting a signal, I find the use of the operator
inappropriate for watches. Replaced with an explicit activate()
method.
While looking at the implementation, I found that this operator and
destructors had been duplicated. Instead of fixing it in all copies, I
moved the common code into a SignalWatch<> base template,
parameterized with the type of callback that it deals with.
This patch changes what is shown to the user and how the user
interacts with the command line. Details below.
"--use-daemon [yes/no]" implies that yes/no is optional (square
brackets!), with "yes" being the option that could be expected for a
plain "--use-daemon" parameter. But the implementation always expects
a "yes" or "no" parameter. The original format suggested was
"--use-daemon[=yes/no]"
This patch switches to that format, changes --use-daemon into --daemon
(to be consistent with --keyring) and enables the same format for
--keyring. Although not documented, 0/f/false and 1/t/true are also
accepted. Because the value becomes part of the parameter, m_argc checks
had to be adapted.
The documentation for "--use-daemon" was inserted in the middle of the
"--keyring documentation".
"Parameter not set" has to be available to the Cmdline caller in the
command line too, in addition to true/false. This was done originally
with a string which is empty, "yes" or "no". Using a tri-state
Cmdline::Bool class makes this a bit more explicit and removes the
ambiguity around what useDaemon() returns (values weren't documented).
When running without --daemon and no daemon available, the
first lines of output were:
ERROR: org.<cryptic error>
[INFO] itodo20: inactive
....
=> The command line should fall back *silently* to running in-process.
=> Error messages should be formatted and logged as such, using SE_LOG_ERROR().
Old code might not have done that and we need to preserve that for compatibility
with frontends, but new code should use [ERROR] as output.
=> D-Bus error messages (as in the case above) must have some user (and developer!)
comprehensible explanation what went wrong. The D-Bus error class itself
is no enough.
Although I haven't tested it, I suspect that the code also would have
re-run the operation in-process after the D-Bus server already
executed it and failed.
I rewrote this so that a check for "daemon available" without error messages
is done first before committing to using the daemon. Once that decision is made,
the command line will not fall back to in-process execution.
Rewrote several error messages. Telling a user of a distro's binary to
"re-configure" is misleading (he didn't configure himself).
"can't" => "cannot", punctuation changes. Not sure whether is always an
improvement, comments welcome.
Comment on coding style: I've used "if ()" instead of "if()" because that is
the GNU recommendation.
This is relevant when running in the background:
- less D-Bus traffic, in particular no DEBUG messages which
are not printed by the (current) clients
- less work done formatting these messages for stdout which
doesn't go anywhere (/dev/null) or worse, gets recorded
in a log file
Long term, a more intelligent solution would be good:
- for interactive debugging, add command line option
- for D-Bus, let clients choose
On AMD64, iterating over a va_list destroys it. So after the
m_parentLogger.messagev() call "args" is invalid and using it
again in StringPrintfV() caused a segfault.
Need to copy and free the va_list.
Starting a sync of "foo@bar" is possible and leads to a server
which has "foo" as m_configName, which is the unnormalized name
passed to it. The new "configName" property must return the
normalized name, otherwise matching it against other normalized
names will fail.
Normalized config names can be compared literally, no need (and
perhaps wrong later on!) to do this case-insensitive.
Removed redundant it == m_sessions.end() check (must be true after
leaving the while() loop) and added punctuation to the message.
It is debateable whether "--monitor foo" without foo running should
succeed (zero return code) or indicate a failure. Let's go with
what the code currently does: no error indicated in the return code.
Implement cmdline with support of dbus server. To enable cmdline
with dbus server, use the option '--use-daemon yes/no' in case that
you enable dbus service when configuration.
In a typical scenario, a new session is created for the purpose of
execution of arguments. It is scheduled with other sessions but with
a highest priority. Once it becomes active, command line call
'Session.Execute', a newly added method to execute command line
arguments.
The config name of a session should be known for dbus clients like
command line. A new property 'configName' is added in the properties
when calling 'Session.GetConfig'.
CTRL-C handling are processed once executing a real sync to dbus
server. It is mapped to invoke 'Session.Suspend' and 'Session.Abort'.
The meaning of '--enable-dbus-service' is expanded accordingly.
'--status' without server means printing all running session in the
dbus server.
'--monitor' could accept an optional config name. If one is given,
only attach to a session of that config, otherwise print an error.
If none is given, pick the first.
The console output of dbus server is useful. Thus, it is necessary
to send them to clients at the same time logging them in the
logging system.
DBusServer acts a Logger to pass logging messages to its parent
logger and send them as signals to clients.
Signal 'Output' is defined with 3 arguments: object path, log level,
output. If dbus server has active session, then the output is
session-specific, the 'object path' argument will be filled with
session object path. Otherwise, the object path of dbus server is
used instead of an empty string for it can't be used as object path.
To support command line in dbus server, it has to avoid stdout and
routing ostream through logging system at the same time sending
signals to dbus clients.
Instead of inheriting from std::stream, here a new class inherits
from std::streambuf, which is to store characters. Re-implement
'overflow' method to control output of command line and redirect
output characters to our logging system.
A new log level 'SHOW' is added in the Logging system. It means
the normal output and the logging system won't add level and prefix
information when putting the information in the logging system.
Redirect outputs of processes started by syncevolution by LogRedirect.
'templateName' property is introduced to present the 'device class'
for a matching device.
The property is optional. There might be templates which only
match one specific model or where the class is so obscure that
showing it is useless.
There are 'template id' and 'template name' concepts inside the core,
'template id' is the handle of the template, user can later use it
to uniquely retrieve the corresponding template, 'template name' on
the other hand is an explict property 'templateName' inside the
template metadata, describing the class of the devices for UI.
'template id' is only used by Cmdline and it use the first entry of
the fingerprint.
The unit of SyncConfig::getAutoSyncDelay/Interval() had been changed to
seconds, but without adapting the syncevo-dbus-server code which uses
these values. Now it uses "seconds" whenever a delay or interval is
stored, like most of the rest of the code.
This patch also adds the unit to the comment for these variables.
While removing the factor of 60 in the conversion to the milliseconds
expected by the Timer class, I noticed that multiplying with 100
is not enough, it has to be 1000. Fixed.
The compiler warned about arithmetic involving time_t and m_interval,
a guint. This patch solves that by making m_interval a time_t and
converting to it once from int.
Assigning a negative value to guint m_interval would have been strange,
and because time_t might be unsigned (?), better always set it to 0
in that case.
The AutoTerm class, responsible for implementing the "terminate server
when idle for x seconds", woke up the process every five seconds to
check whether x seconds had passed since the last D-Bus call. The
regular wakeups increase power consumption and should be avoided.
This patch does that as follows:
- if the server has clients, there is no need for wakeups
because the server is obviously in use
- if it has no clients, sleep for x seconds since the last
D-Bus call (note that ref()/unref() imply D-Bus activity)
- instead of adding/removing the timeout on each D-Bus call,
let the pending one expire and set another one if there has
been activity since the current timeout was created
"No idle timeout" is treated like "server always has one client".
In addition, this patch cleans up a few things:
- remove the timeout when destructing the class; otherwise
it might still fire when the main loop is invoked again
for whatever reason and then segfault when using a stale
pointer
- don't typecast checkCallback() - that hides problems should
that function not match the expected prototype
glib's g_source_attach() does not check for guint ID
overflows. Because we add a timeout at most once per second (in the
unlikely case of 1 second idle timeout and permanent D-Bus activity),
we don't have to worry about that.
This patch passed both manual tests and test-dbus.py
TestDBusServerTerm. There was a missing "m_checkSource = 0" initially,
which was found by failures in TestDBusServerTerm - good to have these!
A crash is caused by erasing the wrong position of iterator for
the auto sync task map. It occurs only when a config is changed.
And the task map has to be changed accordingly. It triggers to erase
existing tasks for the config and then the crash happens.
If a password InfoRequest is timeout and no client sends its
response, use a specific status code '22003' to indicate it.
DBus clients get this status code if this kind of error occurs.
To notify syncevolution core, use exceptions to transfer status code
by defining a new class 'StatusException'.
As mentioned in MB #6175, running as HTTP server no longer worked
because the incoming message was mistaken as SAN message.
This patch solves this by manually reverting the following patch:
commit 12bd955d88
Author: Chen Congwu <congwu.chen@intel.com>
Date: Tue Feb 23 17:01:37 2010 +0800
syncevo-dbus-server: accept SAN 1.0/1.1 pacakge (MB#9312)
Automatic revert did not work because some of the code had been
modified in the meantime.
Reverting this might be the final solution, because we don't need to
support incoming SAN 1.0/1.1. Whoever wants to talk with us should
use SAN 1.2.
If we are contacted by a remote peer via SAN and there is not a configuration
already available, we should create a configuration automatically.
This patch moved part of SAN content matching to Connection.ready, because
creating a configuration needs Session support, that's not available in
Connection.process, defer it to Connection.ready is a safe point.
'PreventSlowSync' was enabled, so that when a sync could not be conducted without
falling back to a slow sync, we will abort the sync and warn the user about this
unnormal condition.
However if the sync session is inited from a remote peer (e.g. Server Alerted
Sync), this kind of warning on our side has no way to convey to the remote peer;
thus causing remote peer confused about the sync failure. It is reasonable to
disable this feature in this kind of scenario because: 1) The remote peer might
not have 'PreventSlowSync' check capability and we must work with them 2) For
SyncEvolution server, this kind of checking should be implemented at server side.
Implement new notification for auto sync according to
requirements. The main changes are messages description
and internationalized.
3 kinds of messages are defined and shown via notification
server: 'is syncing', 'Sync complete' and 'Sync problem'.
They are used in below scenarios:
1) sync is successfully started, show 'is syncing'
2) sync is ended, show 'Sync complete' or 'Sync problem'
3) sync has problem, once sync is not successfully started,
and a fatal error occurs, show 'Sync Problem'. If not a fatal
problem, don't show anything.
To detect when sync is successfully started and done, SessionListener
is defined to listen to these changes. This gives AutoSyncManager
opportunities to send notifications once these statuses are changed.
Two buttons 'Dismiss' and 'View' are added into all notifications
to let users dismiss the notification or pop up sync-ui.
They are implemented by optional 'actions' mechasim of notification.
So if the notification server doesn't support actions, don't add
them.
Also accept SAN 1.1 package, this requres enabling SAN_1_1 build option for
synthesis SDK.
In dbus server, when receving a message with content type 'xml/wbxml', we can
not think it as a client contact us, it may also be possibly a server sending
SAN 1.1 package to us; in this case first take it as a SAN package and try to
parse it, if fails fall back to a normal synchronization message from a client.
The SAN parsing did not fail as expected in the original implementation, thus
a patch for synthesis sdk is essential.
Now we print
[ERROR] g_dbus_setup_bus() failed - server already running?
instead of just
[ERROR] g_dbus_setup_bus() failed
Starting the server twice was the most common reason for the problem.
Unfortunately we cannot be sure, because g_dbus_setup_bus() doesn't set
an error.
1) change the registration order of the properties: before
'preventSlowSync'.
2) newly added 3 properties break unit tests in CmdlineTest.
Fix them.
3) prevent automatic termination when there is any auto sync
task enabled by configs.
4) don't regularly checking auto sync if a config's 'autoSyncInterval'
is set as value '0'. Only do auto sync when changes are detected
in this scenario.
Add notification for auto sync when a task has been
done. Check and use 'libnotify' as a notification
target. Enable it only when enabling dbus server.
Implement automatic sync feature. 3 scenarios are:
1) For a config enables autosync, an interval has passed.
2) Once users log in or resume and an interval has passed. Not
implemented yet.
3) Evolution data server notify any changes. Not implemented yet.
Auto sync manager is to manage all issues of auto sync. In its
initialization step, it reads all configs and check their properties.
If a configuration is enabled with automatic sync, possibly http
or obex-bt or both, one or more tasks for different URLs of each config
are added in the task map grouped by their intervals, holding configured
tasks. Tasks in the map are updated once any config is changed.
Tasks in the map are scheduled and checked when some conditions are met,
such as the interval has passed(the first scenario). Scheduled tasks are
put in the working queue to wait for doing sync. Before a scheduled task
is put in the working queue, it has to be checked whether there is
any existing same task in the working queue.
Once there is any task in the working queue, auto sync manager picks one
task from the working queue and create a session with a lower priority for
it than normal. However, at any time, there is at most one session.
If the session is scheduled and activated by dbus server, it gets
the privilege to do sync. After completion, auto sync manager picks another
task if has and creates a new session. Do this repeatedly unless the
working queue is empty.
The new signal is very minimal without any parameters. Its purpose
is to notify the sync-ui when it has to reread the template configs.
It is triggered by modifying m_syncDevices, which is the input
for the template list.
1) Add description for how to implement this feature and give
comments of each class for bluetooth devices detection
2) Move sync device list from BluezAdapter to DBusServer. Thus
operations on sync device list are also moved to DBusServer.
So 'TemplatesChanged' signal could track device list in a more
reasonable way
3) Once default adapter is changed, remove devices in the sync device
list that belongs to this adapter
4) Other minor changes
Improvement to add signal receivers for signals sent
from bluez. Thus, syncevo-dbus-server could detect
bluetooth devices changed dynamically.
4 signals from bluez are listened:
org.bluez.Manager: AdapterChanged
org.bluez.adapter: DeviceCreated, DeviceRemoved
org.bluez.device: PropertyChanged
To support listening signals from other services,
add support in gdbus cxx bridge.
The syncevo-dbus-server never instantiated an ObexTransportAgent
in its own createTransportAgent() implementation because that code
hadn't been updated.
Instead of duplicating the code for instantiating the various agents,
now DBusSync::createTransportAgent() calls the underlying
SyncContext::createTransportAgent(). It passes its glib main loop
pointer and expects to get an agent which uses that.
It is a bit inconsistent that we have to pass a GMainLoop pointer
through an interface that is supposed to be independent of glib.
Therefore it is declared as "void *". When adding other main loop
integrations, we can either add more parameters or reinterpret the
content of that pointer.
This patch also cleans up the reference counting of the GMainLoop.
Now the reference is no longer handed over to the agent. That solution
was not entirely exception-safe. Instead the constructed agent has to
increase the reference count itself, or do whatever is necessary
instead to keep using the loop. In the ObexTransportAgent, a reference
to the right GMainContext is kept.
As Jussi found out, the CheckSource() D-Bus method always declared
a virtual source as "unusable".
The underlying reason was that instantiating a SyncSource corresponding
to a virtual source config was not possible. If that had worked, it
wouldn't have checked the underlying sources.
This patch fixes both problems by extending VirtualSyncSource (now
instantiates and opens underlying sources) and
SyncSource::createSource() (now recognizes "virtual" and creates a
VirtualSyncSource).
Because creating proper sources depends on the SyncConfig, this must
be passed as parameter into createSource/VirtualSyncSource when
that kind of checking is desired.
Besides opening the underlying sources, VirtualSyncSource::open()
also verifies that it has a proper data format.
I noticed that this code had been copied from SyncSourceSerialize. I
moved the common code into a new SyncSourceBase::getDataTypeSupport().
Error checking also was a bit streamlined. For example, bad or missing
MIME type are detected in SyncSourceBase::getDataTypeSupport(), which
allows us to remove the corresponding check in SyncContext.cpp.
Note that SyncSource::throwError() should be used for source-specific
problems instead of SE_THROW(), because it includes the name of the
source in the exception.
GetConfigs returns related templates to the paired bluetooth
devices with specific scores:
1)Query against the underlying template system via device names
got from Bluez and create a list of templates for each device. Since
there might be many devices and one template from system might be
for more than one device. Thus the template names returned to clients
have to be changed. So the rule to change these templates is:
Bluetooth_<mac address of device>_<seq number>, where seq number enumerates
the templates created for this device.
2)GetConfig would get the template based the cached templates info.
Each template matched for devices is added 4 properties:
description - the description for the template
score - the calculated score based on the device name and template
deviceName - the device name that the template is for
fingerPrint - the fingerPrint of the template, used for dbus clients
to re-match with user input device info
Also, the 'syncURL' will be replaced with bluetooth mac address for
these templates.
1) A possible race condition if checkPresence is called before connman_cb
2) Ensure sending out first set of signals when no connman service avaibale
3) Accpet non-normalized config name and sending normalized config name
