This renames the legacy "evolutionsource/user/password" properties to
"database" and "databaseUser/Password". The justification is that
these properties are also used outside of the Evolution backends.
The change can be done now because the on-disk format has to be
changed anyway in a backward-incompatible way.
The CmdlineTest::testOldConfigure test covers reading an old-style
config.
The goal is to allow multiple names for properties. This will be used
to replace legacy names like "evolutionsource", but it could also be
used to allow abbreviations on the command line.
First the patch replaces the single ConfigProperty::m_name with a list
of names, of which the first one is the current name of the
property.
The name that is to be used depends on the node which is to be
manipulated: if it already has a property under an alias, that alias
is read and also written, so existing configuration continue to use
the old config name (avoids the problem of having to remove the old
name and insert the new one at the same spot in a .ini file). Old
configs continue to parse okay. Writing into node which has none of
the names set, as in migrating into a fresh config, uses the new
names.
Most of the patch deals with the removal of a single, unique name,
either by picking the name so that it matches a node, using the
default name or simply hard-coding a property name ("sync").
The command line accepts all aliases, then uses the main name for
overriding configuration options.
SyncConfig inherited "const char *" from the Funambol C++ API and some
other methods used the same approach for efficient access to plain
strings. However, this has the disadvantage that dynamically generated
strings cannot be returned. SyncConfig had to use an awkward
workaround with a local string cache.
This patch converts most of that code to a normal std::string return
value and removes the string cache.
Out-of-tree backends must be adapted, otherwise they won't compile.
SyncEvolution < 1.2 considered all existing configurations
user-visible in UIs, therefore the ConsumerReady flags was not always
set (done by sync-ui, not done by command line).
In order to keep such old configs visible even when the updated
sync-ui (and soon Genesis) check the flag, the syncevo-dbus-server
transparently adds the flag when it finds a config written by
SyncEvolution < 1.2.
The Cmdline.cpp migration code does the same when rewriting such and
old config for read/write use.
The "*.old" configs get their ConsumerReady flag removed so that UIs
can decide whether they still need to be shown to the user. The
command line will show them, the GTK sync-ui is meant to hide them
(but doesn't to it yet).
Migrating a config in a context wasn't necessary so far, but also
wasn't explicitly forbidden or prevented. It did not work correctly
when the config was identified without explicit context on the command
line, because that short-hand was only mapped correctly before
renaming the config, but not anymore afterward. As a result, the
config was moved into the @default context or possibly some other
context which had a peer with the same name.
Cleaned up the m_server parsing (duplicate code?!) and fixed this
problem by setting m_server to the fully-qualified configuration name,
including a @default suffix. This is user-visible in error messages,
which actually may be a good thing.
The goal is to release SyncEvolution 1.2 with a more recent
libsynthesis, which rewrites its on-disk binfiles such that
older releases are forced to do slow syncs.
This versioning change forces old configs to be migrated. This
affects both the old .sync4j style config (as represented by the
testOldConfigure test) as well as unshared
~/.config/syncevolution/<peer> configs.
gen-autotools.sh now detects pre-releases: have "99" in the version or
the source isn't cleanly tagged. "syncevolution --version" includes
"(pre-release)" if in pre-release mode, otherwise just the version (as
before).
This patch adds version numbers to the on-disk config and files. The
goals are:
1. refuse to use a config which was written by a SyncEvolution release
in a format that is too recent to be handled correctly by the
current release ("detect invalid downgrades")
2. refuse to modify a config in such a way that the previous release
using that config will not be able to use it anymore ("prevent
unintentional upgrade of config")
In the first case the user is told:
SyncEvolution <version> is too old to read configuration '<config>',
please upgrade SyncEvolution.
In the second case the user is told to migrate the configuration manually:
Proceeding would modify config '<config>' such that the
previous SyncEvolution release will not be able to use it.
Stopping now. Please explicitly acknowledge this step by
running the following command on the command line:
syncevolution --migrate '<config>'
These are printed as [ERROR] messages on the command line and shown as
error codes 22004 resp. 22005 in front-ends which don't know about these
scenarios.
The first problem should be rare, so presenting a nicer error messages
in UIs is not essential. But the second problem will occur. The plan
(not implemented yet) is to automatically migrate in stable releases
without asking.
"--migrate @<context name>" would have happily migrated the non-peer
properties, but would not copy the peers inside that context. Wasn't
needed so far, but shouldn't have been allowed either.
Conflicts:
configure-pre.in
src/syncevo/SyncContext.cpp
src/syncevo/configs/datatypes/10calendar-fieldlist.xml
test/ClientTest.cpp
test/client-test-main.cpp
test/synccompare.pl
Conflicts all resolved by using the code from "master" branch. Caused
by similar changes on release branch.
The ScheduleWorld service shut down end of November 2010.
Removing it completely from SyncEvolution is a bit
intrusive (it is used as reference configuration and in
unit tests), so this patch only makes it invisible to
sync-ui users and replaces it in the examples with
Memotoo.
Database backups used to be created unconditionally, even if not
needed for comparison. Now the new "dumpData" variable is
checked. If change printing is enabled, dumping data is implied.
Passing a NULL terminated list of parameters is sometimes a convenient
way of executing certain complex operations. Cmdline testing already did
it, now this is also in the Cmdline class itself.
Backends like XMLRPC need information about URL, proxy and SSL
settings, etc. This can be done via source specific properties, like
evolutionsource, but this is not how this is normally done. It would
be nicer if the exising per-peer properties could be used. The goal is
that a normal peer configuration can be created from a template with
the necessary information to enable sources using that information.
This patch makes this possible by adding a context parameter to
SyncSourceParams:
* @param context Additional non-source config settings.
* When running as part of a normal sync, these are the
* settings for the peer. When running in a local sync,
* these settings come from the "source-config" peer
* config inside the config context of the source.
* Testing uses "source-config@client-test". On the
* command line, this is the config chosen by the
* user, which may or may not have peer-specific settings!
Note that this still doesn't solve the problem for XMLRPC to SyncML
peer sync, because in that case ("normal sync") the context will be
the one describing the peer. SyncURL is already used and proxy
settings might not match.
The XMLRPC backends therefore was not changed and continues to use
evolutionsource.
There was no obvious way of deleting all items. Added * as wildcard
for that. It can be specified in addition to other luids, which
will be ignored if a star is given.
The --import operation was specified as splitting at a blank line and
was meant to work for vCard 3.0 and iCalendar 2.0 files. However, if
the blank line between items used DOS line ends (\r\n) like the items
themselves, then splitting them didn't work because of the literal
match with "\n\n".
This patch introduces a special semantic for the "\n\n" delimiter:
it also matches "\n\r\n" when splitting. This is implemented by
the custom FindDelimiter class.
A context holds a set of source settings, without any peer-specific
properties like "sync mode". The code for configuring such a context
tried to set the sync mode and thus failed.
This patch unifies the check for "configuring context" in one place.
It also slightly modifies the set of sources which are configured:
traditionally, all sources were configured, but only the listed ones
were enabled. This makes sense because users then can enable the source
selectively, either during --run or with --configure without access to
the original template.
For a context, there is no concept of a "disabled" source. Adding
those makes no sense and thus is not done anymore.
Configuring a single source in a new context, adding a second source
and adding a peer is now tested in CmdlineTest::testConfigureSources.
Note that this contains a hack to reflect the broken behavior in BMC
fixed.
Using std::string for both local IDs as respresented by the backend
and encoded as printed by the command line was confusing. It didn't
help that the m_luids member contained encoded strings, instead of
normal luids.
This patch introduces a dedicated class which holds an encoded luid,
and provides the necessary conversion functions. m_luids now really
contains plain luids, so its values can be passed to the backends
directly.
Watching for configuration changes (e.g., for refreshing the list of
servers in the GUI) currently is a bit cumbersome. It requires
watching for SessionChanged, request GetConfigs, and look if
the configs have changed. This is not really a problem, but it
might be more convenient to get notifications about config
changes directly.
This patch introduces a Server.ConfigChanged signal which is at the
end of a session if and only if it modified (removed, updated, added)
a config. This includes the Session.SetConfig() as well as command
line operations executed inside the server.
Testing the signal can only proof that it is emitted. Checking that it
is not emitted would have to block waiting for something, and it is
uncertain what that should be. SessionChanged may be emitted before
the ConfigChange signal and thus isn't suitable.
When configuring a context for local sync, no peer is needed
inside that context. Therefore "--configure" without "--template"
is valid, because the templates only differ in peer-specific
properties.
This patch uses the "SyncEvolution" template as automatic fallback
for context configs. A change to FileConfigTree ensures that the
"peers" directory is created, as expected by the code which checks
for new-style configs.
The --delete-items/--import options did not work with the KCalExtended
backend. The reason was that saving changes is only done in
KCalExtendedSource::endWrite(), which wasn't called because the command
line did not invoke endDataWrite().
That used to be intentional to avoid updating change tracking state in
other backends, but clearly was a hack. Because the sources are now
instantiated without change tracking, endDataWrite() is safe to call,
which fixes the issue with KCalExtended.
'isPropAssignment' checks each line and match whether it's
a property assignment according to match '<word> = value'.
Comments for 'KCalExtended' and 'QtContacts' match this pattern.
Obviously, they should be ignored like other backends comments.
This patch adds an utility script (readme2c.pl) which extracts the
SYNOPSIS and OPTIONS part of README.rst and puts it into C
strings. These are then used inside the SyncEvolution command line for
short help (just the synopsis) and --help (also all options).
This patch also cleans up README.rst so that the OPTIONS part really
documents most options in sufficient detail for --help to be useful.
The USAGE section remains part of the README and the man page where
the different operations are introduced in a more task-oriented way.
This separation is not always easy to make. The --restore operation
and related parameters are only described in the USAGE part because I
couldn't find a way to introduce them briefly and then add a thorough
explanation under OPTIONS.
Some unit tests of CmdlineTest are failed due to new backends
which were newly implemented, including KCalExtended and QtContacts.
Change the reference data.
ZYB.com will be replaced with Vodafone 360, which we don't support (yet).
This patch removes the obsolete template for ZYB.com. The sync-UI still
has some strings for it, just in case that someone has an old template
around or runs it against an old syncevo-dbus-server.
Local IDs were not decoded before invoking the underlying SyncSource
operation. As a result, it failed with "item not found" errors for
those items which really had special characters in their IDs.
Besides the issue with reading the "type" (MBC #3157),
operations like "--print-items @some-context addressbook"
also failed because the TrackingSyncSource would try to write
updated id/rev pairs into a DevNullConfigNode, set because
there is no tracking node in @some-context.
DevNullConfigNode does not allow writing. This patch uses
a set of config nodes where the tracking node is volatile and
allows writing.
The additional benefit also for peer configs is that the SyncSource
can no longer overwrite the change tracking for that peer
accidentally because it never gets access to that node.
This complements --import/update/export/list-items. --remove was
already taken, for deleting a configuration.
Because the removal is done via the normal m_deleteItem operation, we
inherit the normal SyncML behavior (logging, no error return code for
non-existent items). It would have been nice to let the user choose
how to handle that situation (like --force in rm), but that can't be
done without SyncSource API changes.
These operations provide a common interface for manipulating
databases supported by SyncEvolution backends. --delete is
an obvious gap, will be added soon.
The implementation supports all backends offering the SyncSourceRaw
interface (Evolution, Akonadi, XMLRPC, file, but not the sqlite demo),
which is determined via a dynamic cast. SyncSourceRaw is necessary
because it allows direct access to the native data format without
going through the Synthesis engine.
Because the Synthesis engine is not activated, printing the short
description (SyncSourceLogging interface) mentioned in the README.rst
is not possible yet. Having such an engine would be useful also for
importing/exporting data which is not in the native format of the
backend; additional command line parameters will be needed to define
that format.
All of the new operations have in common that they work on one source
and multiple LUIDs. This is a slight deviation from other command line
synopsises where all arguments after the server config refer to sources.
The new m_accessItems flag is set for these special operations; they
also share much of the setup code.
The implementation itself tries to use the generic SyncSource
interface as much as possible. It only falls back to more specialized
implementations where necessary (SyncSourceRaw).
The builtin synopsis and usage was intentionally not updated. The
expection is that before this patch lands in the "master" branch, the
builtin text will come directly from README.rst (which was updated).
Previously, it was possible to list several different operations
on the command line ("--version --configure --run ..."). SyncEvolution
then picked one of them in (for users) unpredictable ways.
Now all requested operations are gathered while parsing the command
line and the tool aborts with an error message listing all of them
if more than one is given.
With this patch, template files are also found in
.config/syncevolution-templates (or the corresponding directory
pointed to by the XDG env variables).
The tests had to be adapted a) to not find templates installed
by the user in his own home and b) to cover finding templates
via XDG_CONFIG_HOME.
A user reported that the default 1 minute resend interval did not work
for him with his own Funambol server installation. The Funambol
developers are notified, but won't be able to do much about this
in the near future.
Therefore this patch disables message resend in the Funambol server
template. Existing configurations have to be updated manually, both
to suppress the resending and to enable it again later.
The default resend interval is also increased from 1 minute to 2
minutes, to help other slow servers which might have problems handling
resends when they arrive to quickly.
There is a regression caused by a string exception
"basic_string::_S_construct NULL not valid". This is because
I push back a non-existing string into vector when collecting
converted command line arguments.
The criteria for not invoking Cmdline::run() was a bit too broad.
For "--template ?", "--help", "--version", "?", "--print-servers" no
output was produced in --daemon mode.
Perhaps the whole m_dontrun logic should be updated. In order to
minimize changes, this patch only duplicates the Cmdline::run()
logic.
argv[0] is skipped by Cmdline::parse(), therefore wasn't added to
the updated argument list for the D-Bus, which then basically
ignored the first command line parameter.
Convert relative paths into absolute paths before passing arguments
to dbus server because command line and dbus may have different working
directory.
Leave this kind of task in Command line for it knows the meaning of
parameters and convert them if necessary.
Add a new function 'relToAbs' to convert a relative path to a
canonicalized absolute path.
Added "--status without config name" comment to help output.
Changed the "No running session(s) just now" into a full sentence,
with a slightly more "positive" twist to it:
"Background sync daemon is idle."
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.
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.
For cases where the Cmdline instance uses a non-standard output stream,
the SyncContext should also use that one. Needs to be tested as
part of MB #5042/5043.
Cmdline and SyncContext standard output should always go
through a variable that can be pointed towards the actual
output channel.
Cmdline already had m_out for that, but it wasn't used
everywhere. Fixed.
SyncContext now has setOutput()/getOutput() and that is
used in SyncContext.cpp. It is not set anywhere yet.
To catch incorrect use of cout or cerr inside SyncEvolution,
the SyncEvo namespace defines its own cout and cerr which cannot
be used like std::cout/cerr, thus triggering compiler
errors. Use "std::cout/cerr" when necessary.
'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.
