8:27 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=9585
Summary: Sync-evo-http server - memo contents lost if created
or edited on client side
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: syncevolutionbugs(a)sourcesink.com
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
This is probably a known issue but I didn't see a bug on it here
(yes, I did see a warning about the main goal currently being bluetooth sync
and not making http sync work - my goal at the moment is to see if I can rely
on this to sync an N900 directly with evolution without bluetooth though - so I
decided to try it)
Client: Maemo 5 SDK under scratch box, syncevolution version 0.92
Server: Evolution version 2.24.3, with syncevolution 1.0 beta 1 - using HTTP
sync
Setup followed process on this page:
http://syncevolution.org/development/http-server-howto
Skipped the server setup part which started with the comment lines below
because I wanted to test syncing directly into evolution and NOT using
a local file.
# Remove the "--source-property type" lines to use the Evolution backends.
# sync=two-way will become redundant once the server is more intelligent
# and knows which sources are active in a sync (MB #7710). The uri
# is reset here because it might be used at some point to rename the
# data source (MB #7871).
Problem Cases:
1) Create a new task on the Maemo 5 environment - go to contacts, click
title bar area, click goto notes, click new note
Create a new note and save as usual
When sync performed, the note inside evolution will
have blank title and contents will also be blank
2) Create a memo inside evolution in the usual fashion
When sync is performed, the Maemo 5 environment under calendar
(Start calendar, click title bar area, click goto notes)
will show up fine. Title and contents are intact at this point.
Edit it by clicking on it and changing the content then click save
Run the sync again
The title and contents displayed in evolution are now blank
The title and contents in the client remain correct with latest edits
shown. Further syncs do not change either side.
Config for server:
maemo@maemo-desktop:~/unpack/synevolution-git/syncevolution$ syncevolution
--print-config n900
# Identifies how to contact the peer,
# best explained with some examples.
# HTTP(S) SyncML servers:
# http://my.funambol.com/sync
# http://sync.scheduleworld.com/funambol/ds
# https://m.google.com/syncml
# OBEX over Bluetooth uses the MAC address, with
# the channel chosen automatically:
# obex-bt://00:0A:94:03:F3:7E
# If the automatism fails, the channel can also be specified:
# obex-bt://00:0A:94:03:F3:7E+16
# syncURL =
# user name used for authorization with the SyncML server
username = maemo
# password used for authorization with the SyncML server;
# in addition to specifying it directly as plain text, it can
# also be read from the standard input or from an environment
# variable of your choice:
# plain text: password = <insert your password here>
# ask: password = -
# env variable: password = ${<name of environment variable>}
password = maemo
# full path to directory where automatic backups and logs
# are stored for all synchronizations; if unset, then
# "${XDG_CACHE_HOME}/syncevolution/<server>" (which
# usually expands to ${HOME}/.cache/...) will be used;
# if "none", then no backups of the databases are made and any
# output is printed directly to the screen
# logdir =
# level of detail for log messages:
# - 0 (or unset) = INFO messages without log file, DEBUG with log file
# - 1 = only ERROR messages
# - 2 = also INFO messages
# - 3 = also DEBUG messages
# > 3 = increasing amounts of debug messages for developers
# loglevel = 0
# enables or disables the detailed (and sometimes slow) comparison
# of database content before and after a sync session
# printChanges = 1
# Unless this option is set, SyncEvolution will never delete
# anything in the "logdir". If set, the oldest directories and
# all their content will be removed after a successful sync
# to prevent the number of log directories from growing beyond
# the given limit.
# maxlogdirs = 10
# During a slow sync, the SyncML server must match all items
# of the client with its own items and detect which ones it
# already has based on properties of the items. This is slow
# (client must send all its data) and can lead to duplicates
# (when the server fails to match correctly).
# It is therefore sometimes desirable to wipe out data on one
# side with a refresh-from-client/server sync instead of doing
# a slow sync.
# When this option is enabled, slow syncs that could cause problems
# are not allowed to proceed. Instead, the affected sources are
# skipped, allowing the user to choose a suitable sync mode in
# the next run (slow sync selected explicitly, refresh sync).
# The following situations are handled:
# - running as client with no local data => unproblematic,
# slow sync is allowed to proceed automatically
# - running as client with local data => client has no
# information about server, so slow sync might be problematic
# and is prevented
# - client has data, server asks for slow sync because all its data
# was deleted (done by Memotoo and Mobical, because they treat
# this as 'user wants to start from scratch') => the sync would
# recreate all the client's data, even if the user really wanted
# to have it deleted, therefore slow sync is prevented
# Slow syncs are not yet detected when running as server and in the
# client when the server's anchor is wrong.
# This option is not enabled by default because it forces users
# to deal with slow syncs, which is a deviation from previous
# behavior.
# preventSlowSync = 0
# set to T to choose an HTTP proxy explicitly; otherwise the default
# proxy settings of the underlying HTTP transport mechanism are used;
# only relevant when contacting the peer via HTTP
# useProxy = 0
# proxy URL (http://<host>:<port>)
# proxyHost =
# authentication for proxy: username
# proxyUsername =
# proxy password, can be specified in different ways,
# see SyncML server password for details
# proxyPassword =
# - empty or "md5" for secure method (recommended)
# - "basic" for insecure method
#
# This setting is only for debugging purpose and only
# has an effect during the initial sync of a client.
# Later it remembers the method that was supported by
# the server and uses that. When acting as server,
# clients contacting us can use both basic and md5
# authentication.
# clientAuthType = md5
# The total amount of time in seconds in which the client
# tries to get a response from the server.
# During this time, the client will resend messages
# in regular intervals (RetryInterval) if no response
# is received or the message could not be delivered due
# to transport problems. When this time is exceeded
# without a response, the synchronization aborts without
# sending further messages to the server.
#
# When acting as server, this setting controls how long
# a client is allowed to not send a message before the
# synchronization is aborted.
# RetryDuration = 300
# The number of seconds between the start of message sending
# and the start of the retransmission. If the interval has
# already passed when a message send returns, the
# message is resent immediately. Resending without
# any delay will never succeed and therefore specifying 0
# disables retries.
#
# Servers cannot resend messages, so this setting has no
# effect in that case.
# RetryInterval = 60
# the identifier sent to the remote peer for a server initiated sync.
# if not set, deviceId will be used instead
# remoteIdentifier =
# Indicates whether this configuration is about a
# client peer or server peer.
PeerIsClient = 1
# An arbitrary name for the peer referenced by this config.
# Might be used by a GUI. The command line tool always uses the
# the configuration name.
# PeerName =
# The SyncML server gets this string and will use it to keep track of
# changes that still need to be synchronized with this particular
# client; it must be set to something unique (like the pseudo-random
# string created automatically for new configurations) among all clients
# accessing the same server.
# myFUNAMBOL also requires that the string starts with sc-pim-
deviceId = sc-pim-3bf40fc6-d61d-4ad6-a531-0902ae9d2c35
# SyncML ID of our peer, empty if unknown; must be set only when
# the peer is a SyncML client contacting us via HTTP.
# Clients contacting us via OBEX/Bluetooth can be identified
# either via this remoteDeviceId property or by their MAC
# address, if that was set in the syncURL property.
#
# If this property is empty and the peer synchronizes with
# this configuration chosen by some other means, then its ID
# is recorded here automatically and later used to verify that
# the configuration is not accidentally used by a different
# peer.
remoteDeviceId = sc-pim-26cd5f07-ff86-48e9-8a6c-2a4b2d9be6ce
# use the more compact binary XML (WBXML) for messages between client and
server;
# not applicable when the peer is a SyncML client, because then the client
# chooses the encoding
# enableWBXML = 1
# The maximum size of each message can be set (maxMsgSize) and the
# peer can be told to never sent items larger than a certain
# threshold (maxObjSize). Presumably the peer has to truncate or
# skip larger items. Sizes are specified as number of bytes.
# maxMsgSize = 20000
# maxObjSize = 4000000
# enable compression of network traffic (not currently supported)
# enableCompression = 0
# A string specifying the location of the certificates
# used to authenticate the server. When empty, the
# system's default location will be searched.
#
# SSL support when acting as HTTP server is implemented
# by the HTTP server frontend, not with these properties.
# SSLServerCertificates =
/etc/ssl/certs/ca-certificates.crt:/etc/pki/tls/certs/ca-bundle.crt:/usr/share/ssl/certs/ca-bundle.crt
# The client refuses to establish the connection unless
# the server presents a valid certificate. Disabling this
# option considerably reduces the security of SSL
# (man-in-the-middle attacks become possible) and is not
# recommended.
# SSLVerifyServer = 1
# The client refuses to establish the connection unless the
# server's certificate matches its host name. In cases where
# the certificate still seems to be valid it might make sense
# to disable this option and allow such connections.
# SSLVerifyHost = 1
# The URL of a web page with further information about the server.
# Used only by the GUI.
WebURL = http://www.scheduleworld.com
# The URI of an icon representing the server graphically.
# Should be a 48x48 pixmap or a SVG (preferred).
# Used only by the GUI.
# IconURI =
# Set to true in a configuration template to indicate
# that the server works well enough and is available
# for normal users. Used by the GUI to limit the choice
# of configurations offered to users.
# Has no effect in a user's server configuration.
ConsumerReady = 1
# the peer which is used by default in some frontends, like the sync-UI
# defaultPeer =
# per-peer (unshared) properties: syncURL, username, password, loglevel,
printChanges, preventSlowSync, useProxy, proxyHost, proxyUsername,
proxyPassword, clientAuthType, RetryDuration, RetryInterval, remoteIdentifier,
PeerIsClient, PeerName, remoteDeviceId, enableWBXML, maxMsgSize, maxObjSize,
enableCompression, SSLServerCertificates, SSLVerifyServer, SSLVerifyHost,
WebURL, IconURI, ConsumerReady
# shared by peers in same context: logdir, maxlogdirs, deviceId
# global properties: defaultPeer
[addressbook]
# requests a certain synchronization mode:
# two-way = only send/receive changes since last sync
# slow = exchange all items
# refresh-from-client = discard all remote items and replace with
# the items on the client
# refresh-from-server = discard all local items and replace with
# the items on the server
# one-way-from-client = transmit changes from client
# one-way-from-server = transmit changes from server
# none (or disabled) = synchronization disabled
sync = two-way
# Specifies the SyncEvolution backend and thus the
# data which is synchronized by this source. Some
# backends can exchange data in multiple formats.
# Some of them have a default format that is used
# automatically unless specified differently.
# Sometimes the format must be specified.
#
# This property can be set for individual peers as
# well as for the context. Different peers in the
# same context can use different formats, but the
# backend must be consistent.
#
# A special 'virtual' backend combines several other
# data sources and presents them as one set of items
# to the peer. For example, Nokia phones typically
# exchange tasks and events as part of one set of
# calendar items.
#
# Right now such a virtual backend is limited to
# combining one calendar source with events and one
# task source. They have to be specified in the
# 'evolutionsource' property, typically like this:
# calendar,todo
#
# In all cases the format of this configuration is
# <backend>[:format]
#
# Different sources combined in one virtual source must
# have a common representation. As with other backends,
# the preferred format can be influenced via the 'format'
# attribute.
# Here are some valid examples:
# contacts - synchronize address book with default vCard 2.1 format
# contacts:text/vcard - address book with vCard 3.0 format
# calendar - synchronize events in iCalendar 2.0 format
# calendar:text/x-vcalendar - prefer legacy vCalendar 1.0 format
# virtual:text/x-vcalendar - a virtual backend using vCalendar 1.0 format
#
# Sending and receiving items in the same format as used by the server for
# the uri selected below is essential. Normally, SyncEvolution and the server
# negotiate the preferred format automatically. With some servers, it is
# necessary to change the defaults (vCard 2.1 and iCalendar 2.0), typically
# because the server does not implement the format selection or the format
# itself correctly.
# Errors while starting to sync and parsing and/or storing
# items on either client or server can be caused by a mismatch between
# type and uri.
#
# Here's the full list of potentially supported backends,
# valid <backend> values for each of them, and possible
# formats. Note that SyncEvolution installations usually
# support only a subset of the backends; that's why e.g.
# "addressbook" is unambiguous although there are multiple
# address book backends.
# Currently active:
# Evolution Address Book = Evolution Contacts = addressbook = contacts =
evolution-contacts
# vCard 2.1 (default) = text/x-vcard
# vCard 3.0 = text/vcard
# The later is the internal format of Evolution and preferred with
# servers that support it. One such server is ScheduleWorld
# together with the "card3" uri.
# Evolution Calendar = calendar = events = evolution-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Task List = Evolution Tasks = todo = tasks = evolution-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Memos = memo = memos = evolution-memos
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-calendar
# The later format is not tested because none of the
# supported SyncML servers accepts it.
# Files in one directory = file
# Stores items in one directory as one file per item.
# The directory is selected via evolutionsource=[file://]<path>.
# It will only be created if the prefix is given, otherwise
# it must exist already. Only items of the same type can
# be synchronized and this type must be specified explicitly
# with both mime type and version.
# Examples for type:
# file:text/plain:1.0
# file:text/x-vcard:2.1
# file:text/vcard:3.0
# file:text/x-vcalendar:1.0
# file:text/calendar:2.0
# Examples for evolutionsource:
# /home/joe/datadir - directory must exist
# file:///tmp/scratch - directory is created
#
# Currently inactive:
# Maemo Calendar = calendar = events = maemo-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Tasks = todo = tasks = maemo-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Notes = memo = memos = notes = journal = maemo-notes
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# SQLite Address Book = addressbook = contacts = sqlite-contacts
# vCard 2.1 (default) = text/x-vcard
# XMLRPC interface = xmlrpc
# Data exchange is done via an XMLRPC interface on the datastore.
# Examples:
# xmlrpc:text/plain:1.0
# xmlrpc:text/x-vcard:2.1
# xmlrpc:text/vcard:3.0
# xmlrpc:text/x-calendar:1.0
# xmlrpc:text/calendar:2.0
type = addressbook:text/vcard
# Picks one of backend data sources:
# enter either the name or the full URL.
# Most backends have a default data source,
# like for example the system address book.
# Not setting this property selects that default
# data source.
# If the backend is a virtual data source,
# this field must contain comma seperated list of
# sub datasources actually used to store data.
# If your sub datastore has a comma in name, you
# must prevent taht comma from being mistaken as the
# separator by preceding it with a backslash, like this:
# evolutionsource=Source1PartA\,PartB,Source2\\Backslash
#
# To get a full list of available data sources,
# run syncevolution without parameters. The name
# is printed in front of the colon, followed by
# the URL. Usually the name is unique and can be
# used to reference the data source. The default
# data source is marked with <default> after the
# URL, if there is a default.
# evolutionsource =
# this is appended to the server's URL to identify the
# server's database
uri = card3
# authentication for backend data source; password can be specified
# in multiple ways, see SyncML server password for details
#
# Warning: setting evolutionuser/password in cases where it is not
# needed, as for example with local Evolution calendars and addressbooks,
# can cause the Evolution backend to hang.
# evolutionuser =
# evolutionpassword =
[calendar]
# requests a certain synchronization mode:
# two-way = only send/receive changes since last sync
# slow = exchange all items
# refresh-from-client = discard all remote items and replace with
# the items on the client
# refresh-from-server = discard all local items and replace with
# the items on the server
# one-way-from-client = transmit changes from client
# one-way-from-server = transmit changes from server
# none (or disabled) = synchronization disabled
sync = two-way
# Specifies the SyncEvolution backend and thus the
# data which is synchronized by this source. Some
# backends can exchange data in multiple formats.
# Some of them have a default format that is used
# automatically unless specified differently.
# Sometimes the format must be specified.
#
# This property can be set for individual peers as
# well as for the context. Different peers in the
# same context can use different formats, but the
# backend must be consistent.
#
# A special 'virtual' backend combines several other
# data sources and presents them as one set of items
# to the peer. For example, Nokia phones typically
# exchange tasks and events as part of one set of
# calendar items.
#
# Right now such a virtual backend is limited to
# combining one calendar source with events and one
# task source. They have to be specified in the
# 'evolutionsource' property, typically like this:
# calendar,todo
#
# In all cases the format of this configuration is
# <backend>[:format]
#
# Different sources combined in one virtual source must
# have a common representation. As with other backends,
# the preferred format can be influenced via the 'format'
# attribute.
# Here are some valid examples:
# contacts - synchronize address book with default vCard 2.1 format
# contacts:text/vcard - address book with vCard 3.0 format
# calendar - synchronize events in iCalendar 2.0 format
# calendar:text/x-vcalendar - prefer legacy vCalendar 1.0 format
# virtual:text/x-vcalendar - a virtual backend using vCalendar 1.0 format
#
# Sending and receiving items in the same format as used by the server for
# the uri selected below is essential. Normally, SyncEvolution and the server
# negotiate the preferred format automatically. With some servers, it is
# necessary to change the defaults (vCard 2.1 and iCalendar 2.0), typically
# because the server does not implement the format selection or the format
# itself correctly.
# Errors while starting to sync and parsing and/or storing
# items on either client or server can be caused by a mismatch between
# type and uri.
#
# Here's the full list of potentially supported backends,
# valid <backend> values for each of them, and possible
# formats. Note that SyncEvolution installations usually
# support only a subset of the backends; that's why e.g.
# "addressbook" is unambiguous although there are multiple
# address book backends.
# Currently active:
# Evolution Address Book = Evolution Contacts = addressbook = contacts =
evolution-contacts
# vCard 2.1 (default) = text/x-vcard
# vCard 3.0 = text/vcard
# The later is the internal format of Evolution and preferred with
# servers that support it. One such server is ScheduleWorld
# together with the "card3" uri.
# Evolution Calendar = calendar = events = evolution-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Task List = Evolution Tasks = todo = tasks = evolution-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Memos = memo = memos = evolution-memos
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-calendar
# The later format is not tested because none of the
# supported SyncML servers accepts it.
# Files in one directory = file
# Stores items in one directory as one file per item.
# The directory is selected via evolutionsource=[file://]<path>.
# It will only be created if the prefix is given, otherwise
# it must exist already. Only items of the same type can
# be synchronized and this type must be specified explicitly
# with both mime type and version.
# Examples for type:
# file:text/plain:1.0
# file:text/x-vcard:2.1
# file:text/vcard:3.0
# file:text/x-vcalendar:1.0
# file:text/calendar:2.0
# Examples for evolutionsource:
# /home/joe/datadir - directory must exist
# file:///tmp/scratch - directory is created
#
# Currently inactive:
# Maemo Calendar = calendar = events = maemo-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Tasks = todo = tasks = maemo-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Notes = memo = memos = notes = journal = maemo-notes
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# SQLite Address Book = addressbook = contacts = sqlite-contacts
# vCard 2.1 (default) = text/x-vcard
# XMLRPC interface = xmlrpc
# Data exchange is done via an XMLRPC interface on the datastore.
# Examples:
# xmlrpc:text/plain:1.0
# xmlrpc:text/x-vcard:2.1
# xmlrpc:text/vcard:3.0
# xmlrpc:text/x-calendar:1.0
# xmlrpc:text/calendar:2.0
type = calendar
# Picks one of backend data sources:
# enter either the name or the full URL.
# Most backends have a default data source,
# like for example the system address book.
# Not setting this property selects that default
# data source.
# If the backend is a virtual data source,
# this field must contain comma seperated list of
# sub datasources actually used to store data.
# If your sub datastore has a comma in name, you
# must prevent taht comma from being mistaken as the
# separator by preceding it with a backslash, like this:
# evolutionsource=Source1PartA\,PartB,Source2\\Backslash
#
# To get a full list of available data sources,
# run syncevolution without parameters. The name
# is printed in front of the colon, followed by
# the URL. Usually the name is unique and can be
# used to reference the data source. The default
# data source is marked with <default> after the
# URL, if there is a default.
# evolutionsource =
# this is appended to the server's URL to identify the
# server's database
uri = cal2
# authentication for backend data source; password can be specified
# in multiple ways, see SyncML server password for details
#
# Warning: setting evolutionuser/password in cases where it is not
# needed, as for example with local Evolution calendars and addressbooks,
# can cause the Evolution backend to hang.
# evolutionuser =
# evolutionpassword =
[memo]
# requests a certain synchronization mode:
# two-way = only send/receive changes since last sync
# slow = exchange all items
# refresh-from-client = discard all remote items and replace with
# the items on the client
# refresh-from-server = discard all local items and replace with
# the items on the server
# one-way-from-client = transmit changes from client
# one-way-from-server = transmit changes from server
# none (or disabled) = synchronization disabled
sync = two-way
# Specifies the SyncEvolution backend and thus the
# data which is synchronized by this source. Some
# backends can exchange data in multiple formats.
# Some of them have a default format that is used
# automatically unless specified differently.
# Sometimes the format must be specified.
#
# This property can be set for individual peers as
# well as for the context. Different peers in the
# same context can use different formats, but the
# backend must be consistent.
#
# A special 'virtual' backend combines several other
# data sources and presents them as one set of items
# to the peer. For example, Nokia phones typically
# exchange tasks and events as part of one set of
# calendar items.
#
# Right now such a virtual backend is limited to
# combining one calendar source with events and one
# task source. They have to be specified in the
# 'evolutionsource' property, typically like this:
# calendar,todo
#
# In all cases the format of this configuration is
# <backend>[:format]
#
# Different sources combined in one virtual source must
# have a common representation. As with other backends,
# the preferred format can be influenced via the 'format'
# attribute.
# Here are some valid examples:
# contacts - synchronize address book with default vCard 2.1 format
# contacts:text/vcard - address book with vCard 3.0 format
# calendar - synchronize events in iCalendar 2.0 format
# calendar:text/x-vcalendar - prefer legacy vCalendar 1.0 format
# virtual:text/x-vcalendar - a virtual backend using vCalendar 1.0 format
#
# Sending and receiving items in the same format as used by the server for
# the uri selected below is essential. Normally, SyncEvolution and the server
# negotiate the preferred format automatically. With some servers, it is
# necessary to change the defaults (vCard 2.1 and iCalendar 2.0), typically
# because the server does not implement the format selection or the format
# itself correctly.
# Errors while starting to sync and parsing and/or storing
# items on either client or server can be caused by a mismatch between
# type and uri.
#
# Here's the full list of potentially supported backends,
# valid <backend> values for each of them, and possible
# formats. Note that SyncEvolution installations usually
# support only a subset of the backends; that's why e.g.
# "addressbook" is unambiguous although there are multiple
# address book backends.
# Currently active:
# Evolution Address Book = Evolution Contacts = addressbook = contacts =
evolution-contacts
# vCard 2.1 (default) = text/x-vcard
# vCard 3.0 = text/vcard
# The later is the internal format of Evolution and preferred with
# servers that support it. One such server is ScheduleWorld
# together with the "card3" uri.
# Evolution Calendar = calendar = events = evolution-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Task List = Evolution Tasks = todo = tasks = evolution-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Memos = memo = memos = evolution-memos
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-calendar
# The later format is not tested because none of the
# supported SyncML servers accepts it.
# Files in one directory = file
# Stores items in one directory as one file per item.
# The directory is selected via evolutionsource=[file://]<path>.
# It will only be created if the prefix is given, otherwise
# it must exist already. Only items of the same type can
# be synchronized and this type must be specified explicitly
# with both mime type and version.
# Examples for type:
# file:text/plain:1.0
# file:text/x-vcard:2.1
# file:text/vcard:3.0
# file:text/x-vcalendar:1.0
# file:text/calendar:2.0
# Examples for evolutionsource:
# /home/joe/datadir - directory must exist
# file:///tmp/scratch - directory is created
#
# Currently inactive:
# Maemo Calendar = calendar = events = maemo-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Tasks = todo = tasks = maemo-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Notes = memo = memos = notes = journal = maemo-notes
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# SQLite Address Book = addressbook = contacts = sqlite-contacts
# vCard 2.1 (default) = text/x-vcard
# XMLRPC interface = xmlrpc
# Data exchange is done via an XMLRPC interface on the datastore.
# Examples:
# xmlrpc:text/plain:1.0
# xmlrpc:text/x-vcard:2.1
# xmlrpc:text/vcard:3.0
# xmlrpc:text/x-calendar:1.0
# xmlrpc:text/calendar:2.0
type = memo
# Picks one of backend data sources:
# enter either the name or the full URL.
# Most backends have a default data source,
# like for example the system address book.
# Not setting this property selects that default
# data source.
# If the backend is a virtual data source,
# this field must contain comma seperated list of
# sub datasources actually used to store data.
# If your sub datastore has a comma in name, you
# must prevent taht comma from being mistaken as the
# separator by preceding it with a backslash, like this:
# evolutionsource=Source1PartA\,PartB,Source2\\Backslash
#
# To get a full list of available data sources,
# run syncevolution without parameters. The name
# is printed in front of the colon, followed by
# the URL. Usually the name is unique and can be
# used to reference the data source. The default
# data source is marked with <default> after the
# URL, if there is a default.
# evolutionsource =
# this is appended to the server's URL to identify the
# server's database
uri = note
# authentication for backend data source; password can be specified
# in multiple ways, see SyncML server password for details
#
# Warning: setting evolutionuser/password in cases where it is not
# needed, as for example with local Evolution calendars and addressbooks,
# can cause the Evolution backend to hang.
# evolutionuser =
# evolutionpassword =
[todo]
# requests a certain synchronization mode:
# two-way = only send/receive changes since last sync
# slow = exchange all items
# refresh-from-client = discard all remote items and replace with
# the items on the client
# refresh-from-server = discard all local items and replace with
# the items on the server
# one-way-from-client = transmit changes from client
# one-way-from-server = transmit changes from server
# none (or disabled) = synchronization disabled
sync = two-way
# Specifies the SyncEvolution backend and thus the
# data which is synchronized by this source. Some
# backends can exchange data in multiple formats.
# Some of them have a default format that is used
# automatically unless specified differently.
# Sometimes the format must be specified.
#
# This property can be set for individual peers as
# well as for the context. Different peers in the
# same context can use different formats, but the
# backend must be consistent.
#
# A special 'virtual' backend combines several other
# data sources and presents them as one set of items
# to the peer. For example, Nokia phones typically
# exchange tasks and events as part of one set of
# calendar items.
#
# Right now such a virtual backend is limited to
# combining one calendar source with events and one
# task source. They have to be specified in the
# 'evolutionsource' property, typically like this:
# calendar,todo
#
# In all cases the format of this configuration is
# <backend>[:format]
#
# Different sources combined in one virtual source must
# have a common representation. As with other backends,
# the preferred format can be influenced via the 'format'
# attribute.
# Here are some valid examples:
# contacts - synchronize address book with default vCard 2.1 format
# contacts:text/vcard - address book with vCard 3.0 format
# calendar - synchronize events in iCalendar 2.0 format
# calendar:text/x-vcalendar - prefer legacy vCalendar 1.0 format
# virtual:text/x-vcalendar - a virtual backend using vCalendar 1.0 format
#
# Sending and receiving items in the same format as used by the server for
# the uri selected below is essential. Normally, SyncEvolution and the server
# negotiate the preferred format automatically. With some servers, it is
# necessary to change the defaults (vCard 2.1 and iCalendar 2.0), typically
# because the server does not implement the format selection or the format
# itself correctly.
# Errors while starting to sync and parsing and/or storing
# items on either client or server can be caused by a mismatch between
# type and uri.
#
# Here's the full list of potentially supported backends,
# valid <backend> values for each of them, and possible
# formats. Note that SyncEvolution installations usually
# support only a subset of the backends; that's why e.g.
# "addressbook" is unambiguous although there are multiple
# address book backends.
# Currently active:
# Evolution Address Book = Evolution Contacts = addressbook = contacts =
evolution-contacts
# vCard 2.1 (default) = text/x-vcard
# vCard 3.0 = text/vcard
# The later is the internal format of Evolution and preferred with
# servers that support it. One such server is ScheduleWorld
# together with the "card3" uri.
# Evolution Calendar = calendar = events = evolution-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Task List = Evolution Tasks = todo = tasks = evolution-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-calendar
# Evolution Memos = memo = memos = evolution-memos
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-calendar
# The later format is not tested because none of the
# supported SyncML servers accepts it.
# Files in one directory = file
# Stores items in one directory as one file per item.
# The directory is selected via evolutionsource=[file://]<path>.
# It will only be created if the prefix is given, otherwise
# it must exist already. Only items of the same type can
# be synchronized and this type must be specified explicitly
# with both mime type and version.
# Examples for type:
# file:text/plain:1.0
# file:text/x-vcard:2.1
# file:text/vcard:3.0
# file:text/x-vcalendar:1.0
# file:text/calendar:2.0
# Examples for evolutionsource:
# /home/joe/datadir - directory must exist
# file:///tmp/scratch - directory is created
#
# Currently inactive:
# Maemo Calendar = calendar = events = maemo-events
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Tasks = todo = tasks = maemo-tasks
# iCalendar 2.0 (default) = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# Maemo Notes = memo = memos = notes = journal = maemo-notes
# plain text in UTF-8 (default) = text/plain
# iCalendar 2.0 = text/calendar
# vCalendar 1.0 = text/x-vcalendar
# SQLite Address Book = addressbook = contacts = sqlite-contacts
# vCard 2.1 (default) = text/x-vcard
# XMLRPC interface = xmlrpc
# Data exchange is done via an XMLRPC interface on the datastore.
# Examples:
# xmlrpc:text/plain:1.0
# xmlrpc:text/x-vcard:2.1
# xmlrpc:text/vcard:3.0
# xmlrpc:text/x-calendar:1.0
# xmlrpc:text/calendar:2.0
type = todo
# Picks one of backend data sources:
# enter either the name or the full URL.
# Most backends have a default data source,
# like for example the system address book.
# Not setting this property selects that default
# data source.
# If the backend is a virtual data source,
# this field must contain comma seperated list of
# sub datasources actually used to store data.
# If your sub datastore has a comma in name, you
# must prevent taht comma from being mistaken as the
# separator by preceding it with a backslash, like this:
# evolutionsource=Source1PartA\,PartB,Source2\\Backslash
#
# To get a full list of available data sources,
# run syncevolution without parameters. The name
# is printed in front of the colon, followed by
# the URL. Usually the name is unique and can be
# used to reference the data source. The default
# data source is marked with <default> after the
# URL, if there is a default.
# evolutionsource =
# this is appended to the server's URL to identify the
# server's database
uri = task2
# authentication for backend data source; password can be specified
# in multiple ways, see SyncML server password for details
#
# Warning: setting evolutionuser/password in cases where it is not
# needed, as for example with local Evolution calendars and addressbooks,
# can cause the Evolution backend to hang.
# evolutionuser =
# evolutionpassword =
# per-peer (unshared) properties: sync, type, uri
# shared by peers in same context: evolutionsource, evolutionuser,
evolutionpassword
....
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.