2:33 p.m.
Hello!
Here's another summary of where we are - and have been in the past
weeks...
SyncEvolution 1.0 keeps us busy. I mentioned a 1.0 beta 3 last week and
already made a pre-release available:
1.0beta2a+20100319+SE+15d4589+SYSYNC+0e94c06 in
http://downloads.syncevolution.org/tmp/
We got some feedback on that from Intel QA and in addition, try to get
one last feature in: command line tool as D-Bus client of the
syncevo-dbus-server (MB #5043). This work is not completed yet, so we
are delaying 1.0 beta 3 a bit so that we can really say that it is
"feature complete" when it goes out.
In terms of feedback, please try out direct sync and automatic sync.
These are the new features in 1.0 which might still have bugs and
usability problems.
MeeGo 1.0 "day one" (= code available) is just around the corner. A more
detailed architecture of it will be also made available at that time.
Without getting ahead of that announcement let me just say that I would
be surprised if SyncEvolution wasn't in MeeGo 1.0...
Development (roughly by week, last week backward):
* Yongsheng: started work on moving command line into D-Bus server
(MB #5041/5042/5043), better status code for InfoRequest timeout
(MB #9636), fixed segfault in autosync code
* Congwu: ongoing work on automatic test script for phones (MB
#9862), dealt with a user report of duplicated calendar events
on the N900 when syncing directly (MB #10224)
* Patrick: ww12 snapshot (including external release so that users
can confirm some issues), finished server suspend/resume
improvements and testing (MB #2425), untagged snapshots now get
a unique version derived from base version and git commit hashes
* Jussi: additional and improved error descriptions, automatic
sync switch, improved device config UI
* Yongsheng: automatic sync in backend (MB #6378), localized
notifications for automatic sync (MB #10000), started to move
command line into D-Bus server (MB #5043)
* Congwu: SAN 1.1 support, ready to be merged by Synthesis; found
and solved a bug in libsynthesis when forcing slow sync for a
virtual source (MB #9907), Ovi.com interoperability testing,
fixes for valgrind errors in OBEX transport, create config in
OBEX SyncML client automatically (MB #6175)
* Patrick: temporary workaround for Qt D-Bus binding issues,
hardening the server's support for suspend/resume (required
adding blob support, analysing/reporting/fixing bugs in
libsynthesis and SyncEvolution), found and fixed regression in
HTTP server mode introduced by recent SAN changes, finished
command line support for shared configs (MB #8048),
libbluetooth3 incompatibility in syncevolution.org binaries (MB
#9289), fix for SAN 1.2->1.1 fallback, fix incorrect D-Bus
shutdown when server is started twice (MB #9991)
* Jussi: fixed two segfaults and some other bugs in sync-UI
* Yongsheng: automatic sync via polling (MB #6378), adapt list of
Bluetooth peers and templates at runtime
* Congwu: helped identifying direct sync issues (MB #9902), Nokia
N7210c template improvements (MB #9907), SAN 1.0 support (MB
#9312)
* Patrick: several server improvements (better testing, handling
resent messages in HTTP server), logdir naming changed in case
of collision (MB #9759), last-minute libbluetooth compatibility
fix for 1.0 beta 2 and better packaging (MB #9289/#9811),
platform workarounds (libical memory bug, Mozilla NSS
initialization), Evolution calendar change tracking fix (minor
race condition), fix for error when logdir doesn't exist, notify
sync-ui when templates change, CouchDB workaround (MB #7877),
improved reporting of "syncevolution died unexpectedly" (MB
#9844)
* Jussi: double-free fix (MB #9869), error message for
"syncevolution died unexpectedly", Bluetooth Panel integration
in Moblin
* Patrick: libical memory corruption workaround, avoid CouchDB
Evolution backend (MB #7877), improved packaging on
syncevolution.org (declare conflicts with system SyncEvolution
MB #9811, Bluetooth compatibility layer MB#9289), better
reporting of segfaults and other aborted syncs (MB #9844), fix
for recently introduced crash on Debian Etch (Mozilla NSS init),
reduced size of logs (MB #8092), avoid Horde mistreating us as a
broken Funambol client (deviceId, MB #9347), preventSlowSync
enabled by default (MB #2416), increased maxMsgSize (was too
slow for large DevInf), completed transition from
text/x-calendar to text/x-vcalendar, more fix for virtual data
sources (type check, segfault MB #9737, name collisions and
aliases MB #9664), more intelligent handling of session dirs (MB
#7708), delay database dump and comparison also in clients (MB
#7710), new SyncSource::isEmpty() API (MB #7708), minimize
database accesses by caching result of listAllItems() (MB #7708)
* Jussi: Ubuntu Hardy GTK workarounds, InfoRequest implementation
--
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:13 p.m.
Hi!
Am Donnerstag, den 25.03.2010, 14:33 +0100 schrieb Patrick Ohly:
In terms of feedback, please try out direct sync and automatic sync.
These are the new features in 1.0 which might still have bugs and
usability problems.
Since I’m currently moving Genesis from commandline usage to D-Bus
communication (sync/reports done, configuration coming next), I’d like
to know how automatic sync can be used via D-Bus. After a quick look, I
didn’t find it in the docs (but maybe I was looking at the wrong
places).
I can’t promise Genesis will be fully migrated when SyncEvolution 1.0 is
released, but I’ll try to have the most important parts done, so I could
at least release a preview version.
Cheers,
Frederik
9:24 p.m.
On Thu, 2010-03-25 at 18:13 +0000, Frederik Elwert wrote:
Am Donnerstag, den 25.03.2010, 14:33 +0100 schrieb Patrick Ohly:
> In terms of feedback, please try out direct sync and automatic sync.
> These are the new features in 1.0 which might still have bugs and
> usability problems.
Since I’m currently moving Genesis from commandline usage to D-Bus
communication (sync/reports done, configuration coming next), I’d like
to know how automatic sync can be used via D-Bus. After a quick look, I
didn’t find it in the docs (but maybe I was looking at the wrong
places).
It's enabled by setting the following sync properties, then starting the
syncevo-dbus-server, or setting them via D-Bus directly. Directly
editing config files while the D-Bus server is running is a loophole -
the server will not detect that (could be added, of course).
# Controls automatic synchronization. Currently,
# automatic synchronization is done by running
# a synchronization at regular intervals. This
# may drain the battery, in particular when
# using Bluetooth!
# Because a peer might be reachable via different
# transports at some point, this option provides
# detailed control over which transports may
# be used for automatic synchronization:
# 0 - don't do auto sync
# 1 - do automatic sync, using whatever transport
# is available
# http - only via HTTP transport
# obex-bt - only via Bluetooth transport
# http,obex-bt - pick one of these
# autoSync = 0
# This is the minimum number of seconds between two
# synchronizations that has to pass before starting
# an automatic synchronization. Can be specified using
# a 1h30m5s format.
#
# Before reducing this interval, consider that it will
# increase resource consumption on the local and remote
# side. Some SyncML server operators only allow a
# certain number of sessions per day.
# The value 0 has the effect of only running automatic
# synchronization when changes are detected (not
# implemented yet, therefore it basically disables
# automatic synchronization).
# autoSyncInterval = 30M
# An automatic sync will not be started unless the peer
# has been available for this duration, specified in seconds
# or 1h30m5s format.
#
# This prevents running a sync when network connectivity
# is unreliable or was recently established for some
# other purpose. It is also a heuristic that attempts
# to predict how long connectivity be available in the
# future, because it should better be available long
# enough to complete the synchronization.
# autoSyncDelay = 5M
I can’t promise Genesis will be fully migrated when SyncEvolution 1.0
is
released, but I’ll try to have the most important parts done, so I could
at least release a preview version.
Once the command line accesses the D-Bus server automatically, even the
command line based Genesis would properly integrate into the system, but
without taking full advantage of it. So it's good to hear that you might
get something working.
--
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.
11:24 p.m.
Patrick Ohly wrote:
On Thu, 2010-03-25 at 18:13 +0000, Frederik Elwert wrote:
> Since I’m currently moving Genesis from commandline usage to D-Bus
> communication (sync/reports done, configuration coming next), I’d like
> to know how automatic sync can be used via D-Bus. After a quick look, I
> didn’t find it in the docs (but maybe I was looking at the wrong
> places).
It's enabled by setting the following sync properties, then starting the
syncevo-dbus-server, or setting them via D-Bus directly. Directly
editing config files while the D-Bus server is running is a loophole -
the server will not detect that (could be added, of course).
Apropos... I was thinking how to solve the problem QA reported: that
autosync works like a black box: you just turn it on and have no idea if
it's working or when it's going to work.
I liked the idea of showing "last synced an hour ago, syncing again in
30 minutes" to solve this the best. Looking at the server code, it
doesn't seem like I can make that sort of estimates though (not without
additional information). Or maybe I can, if I show something more vague
when it seems that a autosync time would be close: "...syncing again soon"?
Any other bright ideas? Some already presented were:
* show the interval in UI: this is ok, but doesn't really fill me
(the user) with confidence that something is happening
* mention the sync method in the last-synced message:
"Last synced an hour ago (automatic sync)": This still doesn't
work right after I enable autosync...
- Jussi
8:15 a.m.
New subject: [SyncEvolution] auto sync (was: Re: status 2010-03-25)
On Thu, 2010-03-25 at 22:24 +0000, Jussi Kukkonen wrote:
Apropos... I was thinking how to solve the problem QA reported: that
autosync works like a black box: you just turn it on and have no idea if
it's working or when it's going to work.
I liked the idea of showing "last synced an hour ago, syncing again in
30 minutes" to solve this the best. Looking at the server code, it
doesn't seem like I can make that sort of estimates though (not without
additional information).
True, we would have to add a D-Bus signal that is sent out each time a
sync is scheduled or descheduled. Trying to guess that in the GUI would
duplicate the logic that is used for that in the server.
Should we send out the remaining minutes regularly while the server is
waiting, say every five minutes, or should the GUI implement its own
countdown? If it is sent regularly, the GUI and API become easier (no
need to do anything except for reacting to the signal, no need for a
"get" method). The drawback is of course coarse update intervals of the
display or frequent D-Bus traffic.
Perhaps we should also inform why a sync is not scheduled yet. "Waiting
for peer to become available", "peer available for x minutes, waiting
for system to settle down" (autoSyncDelay). Not very good explanations,
of course.
Or maybe I can, if I show something more vague
when it seems that a autosync time would be close: "...syncing again soon"?
Same problem - how do you know it is "soon"?
Any other bright ideas? Some already presented were:
* show the interval in UI: this is ok, but doesn't really fill me
(the user) with confidence that something is happening
* mention the sync method in the last-synced message:
"Last synced an hour ago (automatic sync)": This still doesn't
work right after I enable autosync...
The second option is our best bet right now, but I agree, it doesn't
really help much in the "autosync enabled first time" case, exactly when
the user wants some reassurance. Perhaps we should better go for the
more complex solution right away.
--
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.
9:33 a.m.
New subject: [SyncEvolution] auto sync (was: Re: status 2010-03-25)
On Fri, 26 Mar 2010 08:15:02 +0100, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
Should we send out the remaining minutes regularly while the server is
waiting, say every five minutes, or should the GUI implement its own
countdown? If it is sent regularly, the GUI and API become easier (no
need to do anything except for reacting to the signal, no need for a
"get" method). The drawback is of course coarse update intervals of the
display or frequent D-Bus traffic.
At the risk of stating the obvious, please consider the effects on
battery life of any polling process you decide to implement. I'm not an
expert, but I would worry about any kind of logging activity that might
spin the disk up.
All the best,
David
1:28 p.m.
New subject: [SyncEvolution] auto sync (was: Re: status 2010-03-25)
On Sat, 2010-03-27 at 08:33 +0000, David Bremner wrote:
On Fri, 26 Mar 2010 08:15:02 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
>
> Should we send out the remaining minutes regularly while the server is
> waiting, say every five minutes, or should the GUI implement its own
> countdown? If it is sent regularly, the GUI and API become easier (no
> need to do anything except for reacting to the signal, no need for a
> "get" method). The drawback is of course coarse update intervals of the
> display or frequent D-Bus traffic.
>
At the risk of stating the obvious, please consider the effects on
battery life of any polling process you decide to implement. I'm not an
expert, but I would worry about any kind of logging activity that might
spin the disk up.
I agree, the sync-ui should never be forced to poll. None of the D-Bus
messages should result in disk activity, so I'm less worried about
regular status updates sent via D-Bus.
The exception is that these updates really have to be infrequent enough
to be barely noticable (IMHO every 5 minutes would be okay). The
question to the consumers of such an event then becomes: is this too
coarse to be useful?
Jussi, what do you think?
The sync-ui would not be the only consumer of this information. The
patches for making the command line tool a D-Bus client are ready. We
have tentative "--status" and "--monitor" command line options to
query
resp. monitor the daemon. "Tentative" because "--monitor" cannot be
used
to connect to an idle daemon yet, only to a running session. Before we
document it, we probably need to think about the usage a bit more.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
1:48 p.m.
New subject: [SyncEvolution] auto sync
Patrick Ohly wrote:
On Sat, 2010-03-27 at 08:33 +0000, David Bremner wrote:
> At the risk of stating the obvious, please consider the effects on
> battery life of any polling process you decide to implement. I'm not an
> expert, but I would worry about any kind of logging activity that might
> spin the disk up.
There is a serious power draw risk involved with automatic updates, but
I don't think this aspect is significant. The actual syncing is when the
possible problems appear: disk, bluetooth and wireless IO may all be
involved at that point.
I agree, the sync-ui should never be forced to poll. None of the
D-Bus
messages should result in disk activity, so I'm less worried about
regular status updates sent via D-Bus.
The exception is that these updates really have to be infrequent enough
to be barely noticable (IMHO every 5 minutes would be okay). The
question to the consumers of such an event then becomes: is this too
coarse to be useful?
Jussi, what do you think?
No, that's not too coarse. An even more silent option is:
* GetAutosyncStatus() method that returns next estimated sync time
and possible reason/status
* AutosyncStatusChanged-signal that is fired when estimated time or
reason/status changes.
Is there a problem with something like this?
Jussi
9:11 a.m.
New subject: [SyncEvolution] auto sync
On Mon, 2010-03-29 at 12:48 +0100, Jussi Kukkonen wrote:
> The exception is that these updates really have to be
infrequent
enough
> to be barely noticable (IMHO every 5 minutes would be okay). The
> question to the consumers of such an event then becomes: is this too
> coarse to be useful?
>
> Jussi, what do you think?
No, that's not too coarse. An even more silent option is:
* GetAutosyncStatus() method that returns next estimated sync time
and possible reason/status
* AutosyncStatusChanged-signal that is fired when estimated time or
reason/status changes.
Is there a problem with something like this?
No, I don't think so. Feature request for future versions, so let's
track it:
http://bugzilla.meego.com/show_bug.cgi?id=535
"syncevo-dbus-server: notify clients about automatic sync schedule"
--
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.
4427
days inactive
4440
days old
syncevolution@synevolution.org
8 comments
4 participants
participants (4)
-
David Bremner -
Frederik Elwert -
Jussi Kukkonen -
Patrick Ohly