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.
When adding a source "foo" in peer "xyz" which doesn't exist in peer
"abc" using the same context, the new source appeared as new source in
"abc" (okay, by design because of shared properties) and was enabled
(not okay).
It was meant to be disabled via the "sync = disabled" default value,
except that this default had not been changed when implementing MB
Changed that default now. Because "sync" is set explicitly when
configuring sources, this should have no side effects.
The class turned out to be necessary for SyncConfig testing, once that
started to look for configs in the normal locations in $HOME and
$XDG_CONFIG_HOME (separate patch for that).
1) .template.ini renamed to template.ini
2) removed duplicated configuration templates in the test directory, we will use
the real templates for testing.
3) change default template for Nokia phones to Nokia_7210c
Mostly replaced <server> with <config> and added new text about the
new config layout. Did some general updating of the documentation to
match the improvements found in 1.0.
Because sharing of properties is not documented, I added code which
prints that as part of "--print-config". Lists of sync properties are
printed beneath the main sync section in a comment, for source
properties once after all sources.
Added --print-configs and --print-peers as alias for --print-servers.
Somehow after merging, src/templates/Funambol and src/templates/ScheduleWorld
came back. The WebURL change for ScheduleWorld did not make it into all
the right places on master.
This property is meant to be used by the sync-UI to store the
intended spelling of the peer (mixed case) and store characters
which are not valid for config names. Therefore the value needs
to use escaping rules.
Introduced TemplateConfig to abstracting the template configuration structure,
the template metadata used for matching is also parsed here.
The fields introduced in the metadata are:
PeerIsClient: identify whether this is a server side configuration or a client
side configuration.
Fingerprint: the matching string for this template, it is a comma separated string
with each string modeled as: "Manufacture_Model". The first substring is also
used as the name to identify this template so that user can select the template
by this name.
eg:
Nokia 7210c: Nokia_7210c
SyncEvolution server: SyncEvolutionServer, SyncEvolution
ScheduleWorld: ScheduleWorld,default
SyncEvolution client: SyncEvolutionClient, SyncEvolution
Description: this is a just a descriptive string not used for matching.
GetServerTemplates is changed to add another "devices" parameter to identify
it is asking for templates for a list of "devices". Each device is a tuple
<matchstring (devicename), matchMode (server/client/all)>.
TemplateList as the return type, which is a list of class TemplateDescription
so that we can also return enough information for corresponding templates. This
list is sorted by the 3-tuple <finger, rank, name>.
Add MatchServerTemplates method which will iterating all templates inside the
folder and match against the input parameter and finally return a sorted
list of matched templates.
The atcually fuzzy match algorithm is based on a LCS (added in the following
commit).
Cmdline interface is changed accordingly:
--template ? is changed to --template ?[string], so that user use the former
case to match all templates for a tradiontial SyncML client and the latter case
to match templates related to an input string.
SyncConfig API is also renamed (Server -> Peer) because both server/client
configuration/template are handled.
The original configuration template (Funambol and ScheduleWorld) has been moved
to the new template structure (under servers), they also have a .template.ini
file added so that they can be matched and picked up. All templates for
supported servers still have built-in template support in the code as before.
Templates for SyncEvolution based server is also added.
Server side templates are added (Nokia default, Nokia_7210c and SyncEvolutionServer).
Add unit test for the new template match use case.
As requested by Mark, the webURL was changed from
sync.scheduleworld.com to www.scheduleworld.com, which is the
official entry point for browerser. IMHO sync.scheduleworld.com
has always worked, though, and currently still does.
Goosync provides access to Google calendar, tasks and contacts
via SyncML. Google itself only supports contacts. Memos are not
supported by either of them.
This patch only adds the template with the necessary configuration
parameters. We have done no testing with the service, so it is
not marked as "consumer ready" at this time.
The template uses an unspecific "https://your.company/mobilesync/server"
syncURL. The hope is that users just have to replace "your.company"
in many cases.
https is chosen because apparently, many installations are restricted
to that.
"syncevolution --configure" works by copying the config with modified
properties set as filters. This did not work for adding sources because
SyncContext::copy() only worked on *existing* sources.
Changed the semantic of the sourceFilter parameter in
SyncContext::copy() so that it specifies *exactly* which sources are
to be copied instead of acting as a filter.
If the given set is a subset of the existing sources, this does not
change anything (SyncContext.cpp dummy.copy(*this, &activeSources)).
If the given set is a superset, then now the additional sources will
be copied where they were ignored before (Cmdline.cpp). There are no
other calls to SyncConfig::copy(), so this change is safe.
Added a new CmdlineTest to cover this situation.
The command line did not read the global defaultPeer property unless
it found an existing context. This is an unnecessary optimization,
reading from an non-existant context yields no properties except
perhaps for defaultPeer, so we can do that and get the correct
result with and without a context.
Jussi mentioned that he didn't get defaultPeer when reading a
template. Added TestMultipleConfigs.testSharedTemplate to verify
that, but it passes without issues.
Broke while adding support for shared configs. We didn't have a test
for it, therefore this went unnoticed. I have added a test for it
(CmdlineTest::printFileTemplates) and fixed the issue (using the wrong
file layout for templates).
The test depends on having access to installed templates in a known
location, which previously was a problem due to the hard-coded
TEMPLATE_DIR. Now SyncContext::createServerTemplate() checks an env
variable (SYNCEVOLUTION_TEMPLATE_DIR) which is set by most of the
command line tests to prevent reading from there unintentionally and
once to "./templates" to ensure reading from there.
This depends on peer/context awareness in the code which looks for
the old config and renames it. If the old config is not in the same
context as the new one, it is searched by peer name alone. This
works for all old-style configs as well as rewriting a peer inside
the same context.
Without copying this directory, using the migrated configuration will
lead to a slow sync.
SyncEvo::CmdlineTest::testMigrate was extended to cover this problem.
Manually testing shows that the slow sync is indeed avoided with
this change.
remoteDevId must be user-visible, because it is necessary to configure
it in advance when the peer is an HTTP SyncML client.
Also updated several property documentation strings. We have to
explain how they apply when the local side acts as SyncML server
and/or OBEX is involved.
When adding a new peer, existing shared properties must be
preserved. The same applies to migrating (= copying) and old
configuration.
To be consistent, printing templates also needs to take existing
shared properties into account.
Special treatment is necessary for the "type" property: it must be
taken from the peer, not from the existing config, so that the peer
can choose a data format for himself. The peer config must be
consistent with regards to the backend for this to work.
The code is similar to syncevo-dbus-server, but not identical because
temporarily overriding properties is done differently. Therefore
SyncConfig::createServerTemplate() has been left as it is (= unaware
of shared properties).
The client-test SyncEvo::CmdlineTest was updated to cover some
of these case.
Root of the tested configuration files is the "default" context. The
global property "defaultPeer" is thus not covered and must be ignored
in the --print-config output (where it is included).
Removing and scanning for properties of a specific peer must take the
"peers" hierarchy into account. Some tests work with more than one
peer configuration at a time.
The "type" property is duplicated. This is only visible in a file
system dump, not in the --print-config output.
The reference ScheduleWorld config dump uses the order of properties
as in the registry so that it can be converted into the --print-config
.ini format automatically. When the order produced by scanning files is
required, the lines have to be sorted first.
The old sync4j-style config is no longer derived from the reference
ScheduleWorld config. Instead it is stored as plain text; this was
easier than updating the transformation.
One problem found in testMigrate is that obsolete shared properties
are not removed. Removal of obsolete properties was a side effect of
rewriting a config under a new name as part of --migrate; it still
works for per-peer properties. This is a minor feature, so I don't
intend to reimplement this for shared properties.
The tests do not yet cover proper creation of templates when there
are already existing shared properties. Needs to be added together
with a fix for the problem.
A global property is not useful yet at the moment because there is
no way of sharing or reading it outside of a specific peer
configuration. This property will be useful once shared properties
truly work. Adding it now simplifies testing.
The property uses an escape mechanism to store unusual characters,
although that shouldn't be necessary in practice. The motivation is
that it is typically read and written by frontends, which benefit
from the escape mechanism (in contrast to normal users editing the
config file directly).
The property is user-visible, just in case that someone is interested.
That SafeConfigProperty automatically sets the "hidden" flag was
unexpected. Removed that behaviour, in particular given that all
other such nodes already set the flag explicitly anyway.
This patch introduces code changes for the new layout without actually
using it yet. Therefore all existing tests for the older layout
still pass. The new meaning of the former "server name" is introduced:
- A plain string now refers to a peer configuration (can be client
or server).
- The @ sign allows selecting a specific context. Different contexts
have independent sets of local sources and peer definitions.
- An empty peer name selects a view on the configuration which contains
no peer-specific properties. Not fully implemented yet.
The FileConfigTree is instantiated with a root which is one level high
up compare to before this patch (for example,
"~/.config/syncevolution" instead of
"./config/syncevolution/scheduleworld") and then config files include
that dropped level in their relative path name
("scheduleworld/config.ini" instead of "config.ini"). This allows
accessing the global properties in
"~/.config/syncevolution/config.ini" and will be used to move peers
further down the hierarchy
("~/.config/syncevolution/peers/scheduleworld/config.ini").
To keep the output of "--print-servers" consistent, the FileConfigTree
gets another parameter which identifies the subset of the larger tree
that is referenced by this FileConfigTree instance.
One side effect of this change is that FileConfigTree instances are no
longer completely separate. Something to keep in mind when
instantiating SyncContext multiple times (MB#8006).
Code may no longer make assumptions in which config node a property is
stored. This is determined by the new getNode() calls based on the
property attributes (hidden, sharing). The new layout is represented as
a set of config nodes. Older layouts use the same set of nodes with
identical instances assigned to them, if they don't really have separate
files for each of them.
SyncSourceNodes no longer grants direct access to the nodes, to catch
code which incorrectly access a specific node directly. For the same
reason the name of the nodes changed.
Code which needs access to all hidden or all visible properties now
does this via a config node returned by getProperties(). Currently
this is identical to the underlying nodes. Once the new layout is
active, this node will act as a multiplexer which gathers properties
from all underlying nodes when reading and picks the right one when
writing.
The "change ID" parameter for sources has been obsolete for a while
and was removed.
Reorganized the property registration so that it is a bit easier
to see which properties are hidden and which use non-default sharing.
The default sharing is "no sharing".
Some other code was improved while touching it:
- removed useless visibility[] array in favor of a i != 0 check in
SyncConfig::copy()
- added default parameters to save/checkPassword() methods
- some constness definition changes
- Property::getProperty() is a virtual call which could only be
overloaded in one case because the constness was wrong; now
getProperty() always returns the string value and getPropertyValue()
some other kind of representation of it, depending on the
class.
- ConstSyncSourceNodes is based on SyncSourceNodes instead of duplicating
it, which simplifies the implementation.
The simplified SyncSourceAdmin API changed slightly: instead of passing
a pointer to the source's SyncSourceNodes, the default nodes are now
found via the SyncSource pointer. For callers this is a bit less
work and it is more general.
The hidden "last" property hasn't been used since moving to Synthesis
and also is not needed for the new server mode. Some virtual methods
could be removed because they no longer are called. Some comments
referred to an obsolete distinction between properties defined by
libfunambol and SyncEvolution.
We used to have the strings "your SyncML server account name" and
"your SyncML server password" hard-coded in the code which generated
templates. As Jussi pointed out, this is a problem for GUIs which have
to hide these strings from their users.
The purpose of these strings was to have them in configs in cases
where the user forgot to set them, as a reminder.
This path moves the strings into the command line config setup,
thus achieving both of these goals.
Use "peerIsClient" configuration property to decide whether this should be a
Server Alerted Sync Session or a client initated.
Use "remoteIdentifier" as the string sending to the remote peer during SAN so
that remote peer can identifier the server properly.
If this should be, will first generate and send SAN in SyncContext::doSync,
get the client request and inialize the session as server with the received
request.
The Cmdline tests hadn't been updated together with adding the
new options and therefore failed. New properties must be added
to the reference config m_scheduleWorldConfig and new internal
properties also to the props list in testOldConfigure.
While checking the test failures, the following problems were found
and fixed:
- "adminData" property name was used for both sync and source property.
The sync property stores Synthesis device information and was
renamed to "deviceData" to avoid confusion. SyncConfig API calls
renamed accordingly. Property instance now follows syncProp* naming
convention.
- The source "adminData" property was not declared as "hidden"
and therefore showed up in the user-visible config.ini files
and --print-config output. The real value set/get in SyncSourceAdmin
was done correctly via the m_hiddenNode.
The order of the servers dependend on the order in which the
filesystem returned the directory names, in other words, it
was pretty random. Now the list is sorted alphabetically by
the server name.
This was found in the testPrintServers when the order of
the servers started to deviate from the (also unsorted) order
in the reference output.
Previously, sync failed because the datastore configuration specified
no means of storing the admin data (single chunk of text and local ID/remote ID
mapping). This could have been added by configuring the SDK_textdb as
<plugin_admin_module>.
Instead this patch implements the functionality inside SyncEvolution,
using a new ".server.ini" config node for the mapping and an
internal "adminData" property for the admin data text chunk. This is
more natural because it keeps the data under our control.
Authentication is configured via <simpleauthuser/pw>. In contrast to
using the SDK_textdb, this allows choosing the username and password.
Ultimately this should also be done inside SyncEvolution, to avoid
writing the username/password into the XML (unsolved encoding issue)
and into log files (privacy issue).
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 intention is to get rid of the historic and inconsistent
naming of some classes and their corresponding files:
* EvolutionSyncClient = class derived from Funambol's SyncClient,
* SyncEvolutionConfig = SyncEvolution's config
With the strict 'namespace SyncEvo' and the syncevo/ path prefix for
most header files it is no longer necessary to have "SyncEvolution" or
"Evolution" in the names. This patch thus renames as follows:
EvolutionSyncClient => SyncContext
EvolutionSmartPtr => SmartPtr
SyncEvolutionCmdline => Cmdline
SyncEvolutionConfig => SyncConfig
SyncEvolutionUtil => util
The former EvolutionSyncClient always had a role that went beyond just
running a sync, for example it also provided config access. With the
upcoming server support it also won't be just a client. Thus the new
name "SyncContext".
The 'syncevo/' prefix is used throughout the code now.
removed whenever the prefix made it clear that the file belongs
to SyncEvolution. This helps finding incorrect include paths.
Quotes should be used exclusively for SyncEvolution files which don't
have a specific prefix yet (test.h, config.h) to help identifying
them.
2009-10-05 14:49:32 +02:00
Renamed from src/syncevo/SyncEvolutionCmdline.cpp (Browse further)
