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.
--- Begin Message ---
Hello!
Let me summarize what open tasks we currently have in SyncEvolution. I'm
intentionally including much more than what can possibly be covered by the
existing team, in the hope that new developers will step up and take on some of
these additional tasks. I'm using HTML formatting so that links are easier to
click. I'll go back to regular ASCII for other mail, I promise.
This is just an overview. Detailed specification and discussion of individual
tasks should happen in bugzilla.moblin.org, so that we can prioritize and track
them. Whenever there is already an entry, I added the issue number. If you are
interested in working on something, announce it here on the list. As soon as
you are actively working on it, also change the "assigned to" field in bugzilla.
"open" issues are considered essential for the release they are listed under.
"optional" means that we probably could release without them, although that
might not be desirable. "in progress" means that someone is already working on
it, with no help needed at the moment.
0.9
This is considered complete. Let's release it so that the Funambol-based 0.8.1
can be replaced.
Optional: support for Mac OS X and Maemo. Release 0.9 without binaries for
these platforms?!
For Mac OS X there isn't much choice: the code depends on the Funambol "VOCL"
vCard encoder/decoder, which is no longer available. Short of adding it again
(either the old GPL-licensed copy or the current AGPL one) there's nothing that
can be done in 0.9. It should be rewritten to access the Synthesis field list.
0.9.1
First maintenance release.
In progress:
* resend messages - ready for testing post 0.9
* interoperability mobical.net, zyb.com
* internal SyncSource API rewrite (stretching the definition of
"maintenance" a bit, but this is very easy to test - if it compiles, it should
work)
Optional:
* rewrite Mac OS X backend to use field list (depends on API rewrite)
1.0
First release with SyncML server and OBEX support.
In progress:
* incoming OBEX connections
* Synthesis SyncML server API
Open:
* outgoing OBEX connections
* database of URIs for each data category per vendor/device
* redesign and reimplement D-Bus API for GUIs
Optional (roughly sorted by importance and size):
* refactor libsynthesis into data conversion and SyncML parts (libvxx?!)
* automatic syncs: at regular intervals, when local data changes, when
server data changes (push!)
* #5046<http://bugzilla.moblin.org/show_bug.cgi?id=5046> raw file sync source
* #5047<http://bugzilla.moblin.org/show_bug.cgi?id=5047> ODBC sync source
* #5049<http://bugzilla.moblin.org/show_bug.cgi?id=5049> field list sync
source
* #5041<http://bugzilla.moblin.org/show_bug.cgi?id=5041> avoid use of
stdout/cout, route through our own logging code,
#5043<http://bugzilla.moblin.org/show_bug.cgi?id=5043> move command line into
D-Bus server
* #3479<file:///home/pohly/syncevolution/show_bug.cgi?id=3479> EDS: protect
against concurrent editing + revision handling (depends on API changes in EDS)
* #4611<file:///home/pohly/syncevolution/show_bug.cgi?id=4611> join/dejoin
different sources
* #2069<file:///home/pohly/syncevolution/show_bug.cgi?id=2069> Synthesis
error codes and explanation,
#4599<file:///home/pohly/syncevolution/show_bug.cgi?id=4599> Funambol:
"Addressbook:Error 418" shows up in sync ui after syncing an alike contact,
#4576<file:///home/pohly/syncevolution/show_bug.cgi?id=4576> Google: "Fatal dbs
error" when syncing data with google in "delete remote" mode
* #4815<file:///home/pohly/syncevolution/show_bug.cgi?id=4815> Outlook
meeting invitations: timezones
* #3472<file:///home/pohly/syncevolution/show_bug.cgi?id=3472> code cleanup
+ quality improvements +
#3476<file:///home/pohly/syncevolution/show_bug.cgi?id=3476> Klocwork
* #2427:<file:///home/pohly/syncevolution/show_bug.cgi?id=2427> attachments
in iCalendar 2.0 events/todo
* #4774<file:///home/pohly/syncevolution/show_bug.cgi?id=4774> verify a
server's conflict handling policy
*
#<file:///home/pohly/syncevolution/show_bug.cgi?id=2143>2143<file:///home/pohly/syncevolution/show_bug.cgi?id=2143>
service setting changes should be tested with server right away
* #2416<file:///home/pohly/syncevolution/show_bug.cgi?id=2416> intelligent
handling of unexpected slow syncs
* #2428<file:///home/pohly/syncevolution/show_bug.cgi?id=2428> allow aliases
for config options (user=username)
* #2429<file:///home/pohly/syncevolution/show_bug.cgi?id=2429> HTTP AUTH
* #2432<file:///home/pohly/syncevolution/show_bug.cgi?id=2432> rewrite
synccompare in C++
* #3311<file:///home/pohly/syncevolution/show_bug.cgi?id=3311> libsynthesis:
field list <-> XML conversion
* #3313<file:///home/pohly/syncevolution/show_bug.cgi?id=3313> push
notification: via email and IMAP IDLE (or XMMP)
* #3477<file:///home/pohly/syncevolution/show_bug.cgi?id=3477> local timezone
* #3604<file:///home/pohly/syncevolution/show_bug.cgi?id=3604> command line:
use keyring
* #2260<file:///home/pohly/syncevolution/show_bug.cgi?id=2260> need
interface to set useProxy or not
* #3471<file:///home/pohly/syncevolution/show_bug.cgi?id=3471> libsynthesis:
better configuration mechanism + debugging
* #3478<file:///home/pohly/syncevolution/show_bug.cgi?id=3478> additional
information about sync sessions
I have not included improvements to the current GTK GUI. There's plenty of work
left in that area. We rely solely on Jussi for that; I'm sure help in that area
would also be useful, although I'm less sure how to arrange that.
These are all changes related to core infrastructure. Those who don't want to
get involved that deeply can pick up more specialized tasks:
* interoperability testing with additional servers, in particular free (as
in: no dependency on third-party operator) ones: Horde, eGroupware
* adding additional backends: GPE and KDE have been asked for, also Mac OS
calendar sync
* wrap non-SyncML protocols or devices in a SyncML client: extracting data
via PBAP, BarrySync, IrMC, etc. and presenting it as a local data backend in
SyncEvolution would allow syncing of that data with SyncEvolution and other
SyncML servers. Depending on those other protocols it might even be done as
two-way sync.
* more platforms: I already mentioned Mac OS X. Windows anyone?
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
--- End Message ---
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
