6:38 p.m.
Today we are releasing SyncEvolution 1.0 alpha 1, a development
snapshot, "because we can" :-)
In particular, we can:
* synchronize directly with a phone over Bluetooth/OBEX
* accept Bluetooth/OBEX connections in cooperation with obexd 0.19
* run SyncEvolution as a rudimentary HTTP SyncML server
* be reasonably sure that it compiles and runs as well as 0.9.x because
it passes the same nightly testing without known regressions
The main goal of this release is to get feedback on where we are going
with 1.0 and its SyncML server and direct synchronization features. If
you want to get involved, now is a good time because a) there is
something which works and b) there is still time to influence the
final 1.0, scheduled for March 2010.
This is definitely work in progress. Only a source snapshot is made
available, not the usual set of binaries. If you can, compile the latest
source directly from the git repositories and recheck before reporting
issues: http://syncevolution.org/development
The source tar ball itself is at the usual location:
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-0....
Documentation is lacking at the moment. Watch the "Development"
section (http://syncevolution.org/development) for HOWTOs or ask on
the mailing list (http://syncevolution.org/support). Contributions
welcome, as always.
Here is a more complete list of features compared to the stable
release. The full (and up-to-date) list can be retrieved from the
Moblin Bugzilla (MB) issue tracking system with this query:
http://bugzilla.moblin.org/showdependencytree.cgi?id=7892&hide_resolv...
Implemented features are marked with a plus +, open ones with a minus -.
Improved sync-UI:
+ settings for HTTP servers are now done inside the list of
all configs and server templates instead of poping up a
separate window
+ uses the new D-Bus API
+ no longer uses private gconf key to select default peer,
replaced by "defaultPeer" in SyncEvolution config
- the design is a bit tentative and not all of it is implemented;
for example, the triangle in front of server entries cannot
be used to unfold the entry, only the "setup now" button does
that (MB #8315)
- recovery features like restoring from backup and handling of
unexpected slow syncs (MB #2416) are missing
Redesigned and reimplemented D-Bus API:
+ central syncevo-dbus-server controls configurations and sync sessions:
http://syncevolution.org/development/direct-synchronization-aka-syncml-se...
+ accepts incoming SyncML connection requests and messages received by
independent transport stubs (obexd, HTTP server, ...)
+ can be used by multiple user interfaces at once
+ fully documented, see src/dbus/interfaces
+ no longer depends on dbus-glib with hand-written glue code for C++,
instead uses gdbus plus automatic C++ binding generated via C++ templates
- 'syncevolution' command line tool bypasses D-Bus server and runs
sync sessions itself (MB #5043)
- waiting for peer not reported over D-Bus and not shown in sync-ui (MB #2229)
- interactive password request not implemented yet (MB #6376)
- availability of peers not detected (connected for HTTP, paired for
Bluetooth; MB #7700)
- once started, syncevo-dbus-server keeps running forever (MB #7711)
- restoring backups only possible via command line (MB #8144)
Revised configuration layout (MB #8048, design document at
http://syncevolution.org/development/configuration-handling):
+ several peer-independent sync and source properties are shared
between multiple peers
+ they can be accessed without selecting a specific peer, by using an
empty config name or with the new "@<specific context>" syntax
+ user interface in command line and D-Bus API unchanged
+ old configurations can be read and written, without causing
unwanted slow syncs when moving between stable and unstable
SyncEvolution versions
+ old configurations can be migrated with the "--migrate" command
line switch; however, then older SyncEvolution can no longer
access them and migrating more than one old configuration causes
the second or later configuration to loose its "deviceId" property
(which is shared now), causing a slow sync once
- users of the sync-ui will not know about the --migrate option,
so if they have only one configuration, it should be migrated
automatically
SyncML server in general:
+ incoming connections are accepted by syncevo-dbus-server via
the D-Bus Connection API; because this is a "personal SyncML
server", all local data is meant to belong to a single user,
and only one sync session can be active at any point in time
+ different users on the same machine can run their own server,
as long as they ensure that listening for incoming connections
does not conflict with each other (different port in HTTP)
- suspend/resume support is untested (MB #2425)
- an HTTP client which stops sending messages blocks the
server forever (MB #7710)
- automatic backup of server databases is inefficient (done
even when client is not allowed to do a sync; always backs up
all data, including sources which are not active; MB #7708)
- the progress events and statistics reported for a SyncML client
are not generated when running as SyncML server, will require
a fair amount of refactoring in the Synthesis engine (MB #7709)
- the Synthesis serverexample config contains workarounds for
specific phones, but SyncEvolution does not currently use those;
adding new workarounds should be made very simple (MB #7712)
HTTP SyncML server:
+ test/syncevo-http-server.py provides an experimental HTTP server
based on Python and Twisted
- a configuration must be created for each peer manually, including
a remoteDeviceId value that contains the peer's SyncML device ID
(MB #7838)
OBEX SyncML server ("sync with phones"):
+ peers are contacted via a builtin transport that uses libopenobex (MB #5188)
+ Server Alerted Notification (SAN) message triggers syncs
- a configuration must be created for each peer manually, including
a syncURL that contains the peer's MAC address (MB #7838) and correct
settings for generating the SAN message (MB #7871)
- should be integrated into the system's Bluetooth pairing (MB #7089)
OBEX SyncML client:
+ obexd 0.19 contains a plugin which passes SyncML messages to syncevo-dbus-server
- parsing of SAN message is rudimentary and depends on an existing local
configuration, needs to be refined depending on which SyncML server software
it is meant to work with (MB #6175)
Automatic sync (MB #6378):
- no support for the various server push notification mechanisms
- no intelligent detection of local changes
- no regular background sync
- depends on safe handling of concurrent editing, which is blocked
by merging of a new Evolution Data Server API (MB #3479)
Upgrading from 0.9.x:
* Upgrading and downgrading should work seamlessly when using existing
configurations. But this being an alpha, better ensure that you have
backups of both your data and your configurations in
~/.config/syncevolution.
* The new configuration layout is only used when creating new
configurations or explicitly invoking "syncevolution --migrate" (see
above). Such configs cannot be used by older SyncEvolution releases.
SyncEvolution 0.9.2 is still in the pipeline. It is a minor update,
addressing several non-critical issues. All of these are also fixed in
1.0 alpha 1:
- Evolution Address Book: avoid picking CouchDB by default (MB #7877, evolution-couchdb
#479110)
CouchDB address books are appended at the end of the local database
list, otherwise preserving the order of address books. The initial
release of evolution-couchdb in Ubuntu 9.10 is unusable because it
does not support the REV property.
Reordering the entries ensures that the CouchDB address book is not
used as the default database by SyncEvolution, as it happened in
Ubuntu 9.10. Users can still pick it intentionally via
"evolutionsource".
- installation: templates now in $(datadir)/syncevolution/templates (MB #7808)
This are files used internally, meant to be extended by distributors.
Storing them in /etc is no longer supported, but also unlikely to be
needed. Added warnings that these files cannot simply be copied into
.config because they are not complete configurations.
- installation: "make install" populates $(docdir) (MB #7168)
Previously README, COPYING, NEWS, and server READMEs were copied
into syncevolution.org .tar.gz/.deb/.rpm archives as part of
custom make rules and thus missing in other installations.
- autotools + Boost: --with-boost had no effect (MB#7856)
- configure: detect incorrect use of --with-synthesis-src
- stderr redirection: detect "error" messages and show them (MB#7655)
The "GConf Error: Failed to contact configuration server..." error
message was suppressed by the code which catches noise from libraries
invoked by SyncEvolution. Now it is printed as ERROR, making it
easier to detect why running SyncEvolution inside cron needs
additional changes:
http://www.estamos.de/blog/2009/05/08/running-syncevolution-as-cron-job/
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution 0.9.x possible:
http://syncevolution.org/about/contributors
6:43 a.m.
On Wed, 2009-12-02 at 18:38 +0000, Patrick Ohly wrote:
Today we are releasing SyncEvolution 1.0 alpha 1, a development
snapshot, "because we can" :-)
This announcement made it into the LWN.net edition of this week.
Documentation is lacking at the moment. Watch the
"Development"
section (http://syncevolution.org/development) for HOWTOs or ask on
the mailing list (http://syncevolution.org/support).
I expect that we'll need two HOWTOs:
* syncing with a phone
* using SyncEvolution as a HTTP server
* tuning the Synthesis configuration for specific peers
The first two items should describe configuration and troubleshooting.
Congwu, can you do the one about local sync with a phone? I'll do the
one about the HTTP server.
The last item is very much in flux at the moment, because we need to
decide how to handle Synthesis XML configuration. I can add that later.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:03 a.m.
Patrick wrote:
> Documentation is lacking at the moment. Watch the
"Development"
> section (http://syncevolution.org/development) for HOWTOs or ask on
> the mailing list (http://syncevolution.org/support).
I expect that we'll need two HOWTOs:
* syncing with a phone
* using SyncEvolution as a HTTP server
* tuning the Synthesis configuration for specific peers
The first two items should describe configuration and troubleshooting.
Congwu, can you do the one about local sync with a phone?
Ok, I will make it.
I'll do the one about the HTTP server.
The last item is very much in flux at the moment, because we need to
decide how to handle Synthesis XML configuration. I can add that later.
Best Regards,
Congwu
1:42 p.m.
On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
Patrick wrote:
>I expect that we'll need two HOWTOs:
> * syncing with a phone
> * using SyncEvolution as a HTTP server
> * tuning the Synthesis configuration for specific peers
>
>The first two items should describe configuration and troubleshooting.
>Congwu, can you do the one about local sync with a phone?
Ok, I will make it.
=> http://syncevolution.org/development/sync-phone
Some questions about this:
1. Is setting remoteIdentifier necessary? I remember that you found
it to be unnecessary. As long as we are unsure how exactly
phones identify their peers (MAC address or identifier?), we
might be better of not setting remoteIdentifier and thus using
the unique deviceId instead, to allow syncing the same phone
with multiple desktops. Setting "remoteIdentifier=PC Suite" then
becomes a tip for users of phones which depend on it.... [a bit
later]... you already have it under "trouble shooting", so I
think it can be removed at the beginning.
2. When enabling "super" datastore, a hint is needed that this does
not yet work as described with 1.0 alpha 1 (MB #8424). As a
workaround, manually creating the source first should do the
trick (mkdir ~/.config/default/sources/super).
3. When using a "super" datastore, should the user do
"syncevolution myphone super" or "syncevolution myphone calendar
todo"? It seems that setting "uri=super" for calendar and todo
makes the later possible, but doesn't that lead to duplicate
entries in the SAN? "syncevolution myphone super" might not work
because "uri" is not set - is that necessary?
4. Troubleshooting "3. Change your database name" -> Change your
URI, right? The local database name remains fixed, only the name
specified via the "uri" property can be changed.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
2:44 a.m.
Patrick wrote:
On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
=> http://syncevolution.org/development/sync-phone
Some questions about this:
1. Is setting remoteIdentifier necessary? I remember that you found
it to be unnecessary. As long as we are unsure how exactly
phones identify their peers (MAC address or identifier?), we
might be better of not setting remoteIdentifier and thus using
the unique deviceId instead, to allow syncing the same phone
with multiple desktops. Setting "remoteIdentifier=PC Suite" then
becomes a tip for users of phones which depend on it.... [a bit
later]... you already have it under "trouble shooting", so I
think it can be removed at the beginning.
2. When enabling "super" datastore, a hint is needed that this does
not yet work as described with 1.0 alpha 1 (MB #8424). As a
workaround, manually creating the source first should do the
trick (mkdir ~/.config/default/sources/super).
Accept.
3. When using a "super" datastore, should the user do
"syncevolution myphone super" or "syncevolution myphone
calendar
todo"? It seems that setting "uri=super" for calendar and todo
makes the later possible, but doesn't that lead to duplicate
entries in the SAN? "syncevolution myphone super" might not work
because "uri" is not set - is that necessary?
It is expected to be used by:
"syncevolution myphone calendar" to sync with one type or
"syncevolution myphone calendar todo" to sync with both. This will indeed cause
duplicate
source alerts in SAN but now failing the phone at the moment.
"syncevolution myphone super" is not working. Perhaps we will also support
this?
4. Troubleshooting "3. Change your database name" ->
Change your
URI, right? The local database name remains fixed, only the name
specified via the "uri" property can be changed.
Correct!
--
Best Regards,
Congwu
2:54 a.m.
This will indeed cause duplicate source alerts in SAN but now failing
the phone at the moment.
==>
This will indeed cause duplicate source alerts in SAN but *not*
failing
the phone at the moment.
Best Regards,
Congwu
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Chen,
Congwu
Sent: Tuesday, December 08, 2009 10:44 AM
To: Ohly, Patrick
Cc: SyncEvolution
Subject: Re: [SyncEvolution] SyncEvolution 1.0 alpha 1: SyncML server, syncs
with phone
Patrick wrote:
>On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
>=> http://syncevolution.org/development/sync-phone
>
>Some questions about this:
> 1. Is setting remoteIdentifier necessary? I remember that you found
> it to be unnecessary. As long as we are unsure how exactly
> phones identify their peers (MAC address or identifier?), we
> might be better of not setting remoteIdentifier and thus using
> the unique deviceId instead, to allow syncing the same phone
> with multiple desktops. Setting "remoteIdentifier=PC Suite" then
> becomes a tip for users of phones which depend on it.... [a bit
> later]... you already have it under "trouble shooting", so I
> think it can be removed at the beginning.
> 2. When enabling "super" datastore, a hint is needed that this does
> not yet work as described with 1.0 alpha 1 (MB #8424). As a
> workaround, manually creating the source first should do the
> trick (mkdir ~/.config/default/sources/super).
Accept.
> 3. When using a "super" datastore, should the user do
> "syncevolution myphone super" or "syncevolution myphone
>calendar
> todo"? It seems that setting "uri=super" for calendar and todo
> makes the later possible, but doesn't that lead to duplicate
> entries in the SAN? "syncevolution myphone super" might not work
> because "uri" is not set - is that necessary?
It is expected to be used by:
"syncevolution myphone calendar" to sync with one type or
"syncevolution myphone calendar todo" to sync with both. This will indeed
cause duplicate
source alerts in SAN but now failing the phone at the moment.
"syncevolution myphone super" is not working. Perhaps we will also support
this?
> 4. Troubleshooting "3. Change your database name" -> Change your
> URI, right? The local database name remains fixed, only the name
> specified via the "uri" property can be changed.
Correct!
>--
Best Regards,
Congwu
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
7:53 a.m.
On Tue, 2009-12-08 at 02:44 +0000, Chen, Congwu wrote:
Patrick wrote:
>On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
>=> http://syncevolution.org/development/sync-phone
[...]
> 3. When using a "super" datastore, should the user
do
> "syncevolution myphone super" or "syncevolution myphone
>calendar
> todo"? It seems that setting "uri=super" for calendar and
todo
> makes the later possible, but doesn't that lead to duplicate
> entries in the SAN? "syncevolution myphone super" might not work
> because "uri" is not set - is that necessary?
It is expected to be used by:
"syncevolution myphone calendar" to sync with one type or
"syncevolution myphone calendar todo" to sync with both.
Somehow I doubt that "syncevolution myphone calendar" really does sync
only the events in "calendar". What I expect to happen (please correct
me if I get this wrong):
* we add an entry for "calendar" to the SAN which tells the phone
to sync with "text/x-vcalendar" to "super"
* phone does that, sending its events and todos
* our "super" virtual data source is active, likewise syncing both
"calendar" and "todo" under the hood
This will indeed cause duplicate
source alerts in SAN but not failing the phone at the moment.
I can imagine that some phones will get confused by this.
"syncevolution myphone super" is not working. Perhaps we
will also support this?
I find it pretty natural to activate the "super" data source,
considering that this is what is getting synced. We should support it.
The semantic that we export to the user then becomes:
* when you have a virtual data source configured, then activating
any of individual data sources or the virtual data source
includes all data in the virtual data source in the sync session
* all of these sources must use the same sync mode
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:14 a.m.
On Tue, 2009-12-08 at 02:44 +0000, Chen, Congwu wrote:
> Patrick wrote:
> >On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
> >=> http://syncevolution.org/development/sync-phone
[...]
> > 3. When using a "super" datastore, should the user do
> > "syncevolution myphone super" or "syncevolution myphone
> >calendar
> > todo"? It seems that setting "uri=super" for calendar and
todo
> > makes the later possible, but doesn't that lead to duplicate
> > entries in the SAN? "syncevolution myphone super" might not
work
> > because "uri" is not set - is that necessary?
> It is expected to be used by:
> "syncevolution myphone calendar" to sync with one type or
> "syncevolution myphone calendar todo" to sync with both.
Somehow I doubt that "syncevolution myphone calendar" really does sync
only the events in "calendar". What I expect to happen (please correct
me if I get this wrong):
* we add an entry for "calendar" to the SAN which tells the phone
to sync with "text/x-vcalendar" to "super"
* phone does that, sending its events and todos
* our "super" virtual data source is active, likewise syncing both
"calendar" and "todo" under the hood
Mostly, the "todo" items sent from the server will be rejected by the
local backend.
And the client will not sending "todo" items too. This works effectively as only
syncing
"todo" items I think.
> This will indeed cause duplicate
> source alerts in SAN but not failing the phone at the moment.
I can imagine that some phones will get confused by this.
> "syncevolution myphone super" is not working. Perhaps we will also
support
this?
I find it pretty natural to activate the "super" data source,
considering that this is what is getting synced. We should support it.
The semantic that we export to the user then becomes:
* when you have a virtual data source configured, then activating
any of individual data sources or the virtual data source
includes all data in the virtual data source in the sync session
* all of these sources must use the same sync mode
I would also like to support syncing only calendar or todo, if my above comments
made sense.
Best Regards,
Congwu
8:37 a.m.
On Tue, 2009-12-08 at 08:14 +0000, Chen, Congwu wrote:
>
>On Tue, 2009-12-08 at 02:44 +0000, Chen, Congwu wrote:
>> Patrick wrote:
>> >On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
>> >=> http://syncevolution.org/development/sync-phone
>[...]
>Somehow I doubt that "syncevolution myphone calendar" really does sync
>only the events in "calendar". What I expect to happen (please correct
>me if I get this wrong):
> * we add an entry for "calendar" to the SAN which tells the phone
> to sync with "text/x-vcalendar" to "super"
> * phone does that, sending its events and todos
> * our "super" virtual data source is active, likewise syncing both
> "calendar" and "todo" under the hood
Mostly, the "todo" items sent from the server will be rejected by the local
backend.
We are the server, the phone is the client. Do you mean client here?
Care to explain? I don't see why or where the todo items would be
rejected.
And the client will not sending "todo" items too. This
works
effectively as only syncing
"todo" items I think.
Again, I don't see why we would not send "todo" items when the
"super"
data source is active.
>The semantic that we export to the user then becomes:
> * when you have a virtual data source configured, then activating
> any of individual data sources or the virtual data source
> includes all data in the virtual data source in the sync session
> * all of these sources must use the same sync mode
>
I would also like to support syncing only calendar or todo, if my above comments
made sense.
Even if we can get it to work, is it guaranteed that the two peers
remain in sync?
Normally, doing a "syncevolution ... calendar" followed by a
"syncevolution ... todo" has exactly the same effect as a
"syncevolution ... calendar todo".
Not so when the "syncevolution ... calendar" discards changes made to
"todo" that the peer is sending us. We cannot count on the peer sending
us these changes again the next time, even if we reject the changes with
a "temporary" status code.
I had asked Lukas that on the Synthesis mailing list. The Synthesis
engine is smart enough to distinguish between temporary and final status
codes, but a) many servers always sent a 500 status code, regardless
what their problem was and b) clients do not check the exact status
code.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:57 a.m.
Patrick wrote:
We are the server, the phone is the client. Do you mean client here?
Correct.
Care to explain? I don't see why or where the todo items would
be
rejected.
This is done by synthesis, during subdatastore dispatching, if it failed to
find a corresponding backend, it rejects.
> And the client will not sending "todo" items too. This
works
> effectively as only syncing
> "todo" items I think.
Again, I don't see why we would not send "todo" items when the
"super"
data source is active.
This is possible when "super" only has "calendar" as subtype.
(Setting todo as "inactive", there still need some support on this).
> >The semantic that we export to the user then becomes:
> > * when you have a virtual data source configured, then activating
> > any of individual data sources or the virtual data source
> > includes all data in the virtual data source in the sync session
> > * all of these sources must use the same sync mode
> >
> I would also like to support syncing only calendar or todo, if my above
comments
> made sense.
Even if we can get it to work, is it guaranteed that the two peers
remain in sync?
I had asked Lukas that on the Synthesis mailing list. The Synthesis
engine is smart enough to distinguish between temporary and final status
codes, but a) many servers always sent a 500 status code, regardless
what their problem was and b) clients do not check the exact status
code.
That maybe the problem... The configuration of 'super', 'calendar'
'todo' duplicates
a lot, I am thinking we may come up with some kind of sharing config node to keep
them in sync.
Best Regards,
Congwu
9:54 a.m.
On Tue, 2009-12-08 at 08:57 +0000, Chen, Congwu wrote:
Patrick wrote:
>We are the server, the phone is the client. Do you mean client here?
Correct.
>Care to explain? I don't see why or where the todo items would be
>rejected.
This is done by synthesis, during subdatastore dispatching, if it failed to
find a corresponding backend, it rejects.
But we are not yet configuring the Synthesis engine like this, do we? At
the moment, whenever the "super" source is active, it always dispatches
to both "calendar" and "todo", doesn't it?
>> >The semantic that we export to the user then becomes:
>> > * when you have a virtual data source configured, then activating
>> > any of individual data sources or the virtual data source
>> > includes all data in the virtual data source in the sync session
>> > * all of these sources must use the same sync mode
>> >
>> I would also like to support syncing only calendar or todo, if my above
>comments
>> made sense.
>
>Even if we can get it to work, is it guaranteed that the two peers
>remain in sync?
>I had asked Lukas that on the Synthesis mailing list. The Synthesis
>engine is smart enough to distinguish between temporary and final status
>codes, but a) many servers always sent a 500 status code, regardless
>what their problem was and b) clients do not check the exact status
>code.
>
That maybe the problem... The configuration of 'super', 'calendar'
'todo' duplicates
a lot, I am thinking we may come up with some kind of sharing config node to keep
them in sync.
That would be hard to implement. The config node sharing doesn't know
anything about such semantic relationships between sources.
I'd prefer to leave the config system as it is and clearly document (and
check) what is required for consistency.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:18 p.m.
New subject: [SyncEvolution] super datastore (was: RE: SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone)
Hello!
We need to come to some conclusion on the proper handling of the super
datastore configuration. Currently we have code in "master" which
already implements a super datastore for the "calendar+todo" use case
(OVI.com, phone), but my understanding is that it will break unless
configured correctly.
See below for my open questions, plus some additional comments.
On Tue, 2009-12-08 at 10:54 +0100, Patrick Ohly wrote:
On Tue, 2009-12-08 at 08:57 +0000, Chen, Congwu wrote:
> Patrick wrote:
> >We are the server, the phone is the client. Do you mean client here?
> Correct.
> >Care to explain? I don't see why or where the todo items would be
> >rejected.
> This is done by synthesis, during subdatastore dispatching, if it failed to
> find a corresponding backend, it rejects.
But we are not yet configuring the Synthesis engine like this, do we? At
the moment, whenever the "super" source is active, it always dispatches
to both "calendar" and "todo", doesn't it?
> >> >The semantic that we export to the user then becomes:
> >> > * when you have a virtual data source configured, then
activating
> >> > any of individual data sources or the virtual data source
> >> > includes all data in the virtual data source in the sync
session
> >> > * all of these sources must use the same sync mode
> >> >
> >> I would also like to support syncing only calendar or todo, if my above
> >comments
> >> made sense.
> >
> >Even if we can get it to work, is it guaranteed that the two peers
> >remain in sync?
> >I had asked Lukas that on the Synthesis mailing list. The Synthesis
> >engine is smart enough to distinguish between temporary and final status
> >codes, but a) many servers always sent a 500 status code, regardless
> >what their problem was and b) clients do not check the exact status
> >code.
> >
> That maybe the problem... The configuration of 'super', 'calendar'
'todo' duplicates
> a lot, I am thinking we may come up with some kind of sharing config node to keep
> them in sync.
That would be hard to implement. The config node sharing doesn't know
anything about such semantic relationships between sources.
I'd prefer to leave the config system as it is and clearly document (and
check) what is required for consistency.
I've previously argued that running something like "syncevolution ...
calendar" in a configuration that has a "calendar+todo" super datastore
should implicitly activate the "calendar+todo" source. I'm no longer
sure whether that is a good idea, because we cannot reliably exclude the
"todo" part from the sync and enable it again later.
That leaves "syncevolution ... calendar+todo". This is valid, but it
means that the core is going to called with both "calendar" and
"todo"
disabled, because the front end is too dumb (and should remain dumb!) to
know that "calendar+todo" depends on them.
To handle this, I think we should declare that the "sync" property of
sources which are merged into a super datastore are ignored. That
setting must be taken from the super datastore config. Inconsistent
settings are not an error, because the "syncevolution ... calendar+todo"
command line invocation will lead to such an "inconsistent" config.
A config for a peer with a super datastore should not set "uri"
properties for the sub-datastores. This will automatically have the
effect that the sync-UI will show those sub-datastores as greyed-out and
prevent setting their "sync" mode.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3:12 p.m.
New subject: [SyncEvolution] super datastore (was: RE: SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone)
On Mon, 14 Dec 2009, Ohly, Patrick wrote:
Hello!
We need to come to some conclusion on the proper handling of the super
datastore configuration. Currently we have code in "master" which
already implements a super datastore for the "calendar+todo" use case
(OVI.com, phone), but my understanding is that it will break unless
configured correctly.
See below for my open questions, plus some additional comments.
On Tue, 2009-12-08 at 10:54 +0100, Patrick Ohly wrote:
> On Tue, 2009-12-08 at 08:57 +0000, Chen, Congwu wrote:
> > Patrick wrote:
> > >We are the server, the phone is the client. Do you mean client here?
> > Correct.
> > >Care to explain? I don't see why or where the todo items would be
> > >rejected.
> > This is done by synthesis, during subdatastore dispatching, if it failed to
> > find a corresponding backend, it rejects.
>
> But we are not yet configuring the Synthesis engine like this, do we? At
> the moment, whenever the "super" source is active, it always dispatches
> to both "calendar" and "todo", doesn't it?
Yes, but it
is achieveable, just generating the subdatastore that is actually
active.
This was the idea before, but you have pointed rejecting the sync items can not
gurantee the phone understands this and may casuse the peers out of sync.
That's possible, so "enabling always both sync source" (treating calendar
and
todo always as a single sync source) seems the right position.
>
> > >> >The semantic that we export to the user then becomes:
> > >> > * when you have a virtual data source configured, then
activating
> > >> > any of individual data sources or the virtual data source
> > >> > includes all data in the virtual data source in the sync
session
> > >> > * all of these sources must use the same sync mode
> > >> >
I've previously argued that running something like "syncevolution ...
calendar" in a configuration that has a "calendar+todo" super datastore
should implicitly activate the "calendar+todo" source. I'm no longer
sure whether that is a good idea, because we cannot reliably exclude the
"todo" part from the sync and enable it again later.
I think we will
always export 'calendar+todo' as a whole to user. Syncing part
of the syncsource should not be allowed.
This also means testing a superdatastore, only need to activate the
superdatastore source (which will automatically activate all sub datastores).
That leaves "syncevolution ... calendar+todo". This is valid, but it
means that the core is going to called with both "calendar" and
"todo"
disabled, because the front end is too dumb (and should remain dumb!) to
know that "calendar+todo" depends on them.
To handle this, I think we should declare that the "sync" property of
sources which are merged into a super datastore are ignored. That
setting must be taken from the super datastore config. Inconsistent
settings are not an error, because the "syncevolution ... calendar+todo"
command line invocation will lead to such an "inconsistent" config.
Ignoring duplicated properties is prefered. So 'sync' and
'uri'should be
set in the virtual datasource, the sub datasource should take these two
properties as ignored. No inconsistence check is needed for the two.
To implement this, when instatiating a virtual datasource, it will cause
all sub datasources be enabled the same time and the 'sync' and 'uri'
property
is set temporarily from the value in virtual datasource.
There is still one property left need some consistence check: 'type'. It cannot
be simply merged, because a sub-datastore may still use it to identify it's
specific backend. However the 'format' part must be exactly the same for all
subdatastores and the virtual datastore.
A config for a peer with a super datastore should not set
"uri"
properties for the sub-datastores. This will automatically have the
effect that the sync-UI will show those sub-datastores as greyed-out and
prevent setting their "sync" mode.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
Regards,
Chen Congwu
Moblin China Development
3:45 p.m.
New subject: [SyncEvolution] super datastore (was: RE: SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone)
On Mon, 2009-12-14 at 15:12 +0000, Chen, Congwu wrote:
On Mon, 14 Dec 2009, Ohly, Patrick wrote:
> To handle this, I think we should declare that the "sync" property of
> sources which are merged into a super datastore are ignored. That
> setting must be taken from the super datastore config. Inconsistent
> settings are not an error, because the "syncevolution ... calendar+todo"
> command line invocation will lead to such an "inconsistent" config.
Ignoring duplicated properties is prefered. So 'sync' and 'uri'should be
set in the virtual datasource, the sub datasource should take these two
properties as ignored. No inconsistence check is needed for the two.
To implement this, when instatiating a virtual datasource, it will cause
all sub datasources be enabled the same time and the 'sync' and 'uri'
property
is set temporarily from the value in virtual datasource.
Sounds like the right approach to me.
There is still one property left need some consistence check:
'type'. It cannot
be simply merged, because a sub-datastore may still use it to identify it's
specific backend. However the 'format' part must be exactly the same for all
subdatastores and the virtual datastore.
Agreed.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:01 a.m.
New subject: [SyncEvolution] super datastore (was: RE: SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone)
Implemented in
http://git.moblin.org/cgit.cgi/syncevolution/commit/?h=phone&id=5c4c8...
Best Regards,
Congwu
10:43 a.m.
On Thu, 2009-12-03 at 06:43 +0000, Patrick Ohly wrote:
On Wed, 2009-12-02 at 18:38 +0000, Patrick Ohly wrote:
> Documentation is lacking at the moment. Watch the "Development"
> section (http://syncevolution.org/development) for HOWTOs or ask on
> the mailing list (http://syncevolution.org/support).
I expect that we'll need two HOWTOs:
* syncing with a phone
* using SyncEvolution as a HTTP server
Just published this:
http://syncevolution.org/development/http-server-howto
Comments welcome.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4577
days inactive
4591
days old
syncevolution@synevolution.org
15 comments
3 participants
participants (3)
-
Chen Congwu -
Chen, Congwu
-
Patrick Ohly