Hello everyone!
Here's some background information about when we might release updates
for SyncEvolution. This isn't set in stone; think of it more like the
grand master plan that we strive for... and then change after impact
with the real world ;-)
Scheduling is driven by "release when ready" and "we want regular
updates at a deterministic point in time", so let's look at the feature
list first:
The high-level goals for 0.9.1 are:
* bug fixing, including string changes that we had to postpone in
0.9
* include message resend (merged, found problems in testing)
* revised backend API (merged, no regressions so far)
*
mobical.net interoperability
* Memotoo interoperability (because of user demand)?
* stretch goal: revised D-Bus API
Message resending was merged, but then a thorough testing against
Funambol and ScheduleWorld showed that there is one particular case
where the sync hangs when a certain message reply gets lost. This looks
like a server bug. With the Synthesis server it works.
The high-level goals for 1.0 are:
* implement revised D-Bus API and architecture (support Genesis
GUI; syncevolution as D-Bus client)
* performance and reliability improvements (EDS API)
* minimal support in sync-ui for SyncML server mode
* stretch goal: implement the intended SyncML client design in
sync-ui (current one is lacking recovery features, progress spinner,
etc.)
* stretch goal: OBEX support for SyncML client and server
* SyncML server mode (peers to be decided)
In particular the last item has a huge tail of detailed testing work
associated with each peer. For 1.0, our goal has to be to get the
infrastructure in place and prove that it works with a few phones. We
probably could work this forever. At the same time we want to get
another stable release out the door so that we can ship the other
improvements.
The biggest unknown factor for 1.0 are the necessary changes in
libsynthesis. Lukas has reassured me that he has made good progress
towards those, but they have a business to run and therefore might have
more important work to deal with first. September 4th in the schedule
below is way too early - more realistic proposals welcome ;-}
With that in mind, here are some milestones that could get us towards 1.0,
with names attached to the major tasks and until when they need to be done
to stay on track:
* Jussi, Patrick, August 26: decide about D-Bus server-side
technology - done, let's use libdbus + gdbus + custom C++ binding
* Patrick, August 28: core server engine and complete C++ binding -
much of that is done.
* Jussi, August 28: D-Bus GUI API redefined, with feedback by others -
still a bit of work needed
* Patrick, Yongsheng, September 11: new D-Bus API implemented (must
work incrementally, so that Jussi can adapt the GUI in parallel)
* Synthesis, September 4 (?): SyncML server API discussed and usable
* Jussi + Patrick + Nick, September 9+10: face-to-face in London,
discuss design issues
* Congwu, September 4: EDS API enhancements + usage of those in
SyncEvolution backends - patches ready for review, Ross will do
that for EDS, Patrick for SyncEvolution
* Congwu, September 11: outgoing OBEX connections with transport
inside SyncEvolution
* Patrick, September 18: Synthesis server feature integrated into
SyncEvolution
* all, end of September: first alpha
* all, end of October: final release
We have to be aware that we have to leave enough gaps in the schedule
for unexpected problems or requests and the "optional" open issues (see
attachment). I consider some of these important that I don't want to
push them out forever:
* code cleanup
* revive SQLite demo backend and perhaps Mac OS X and Maemo
support (although I really hope that the later two will be
covered by external developers)
* split data transformation part out of libsynthesis
--
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.