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 raw file sync source
#5047 ODBC sync source
#5049 field list sync source
#5041 avoid use of stdout/cout, route through our own logging code, #5043 move command line into D-Bus server
#3479 EDS: protect against concurrent editing + revision handling (depends on API changes in EDS)
#4611 join/dejoin different sources
#2069 Synthesis error codes and explanation, #4599 Funambol: "Addressbook:Error 418" shows up in sync ui after syncing an alike contact, #4576 Google: "Fatal dbs error" when syncing data with google in "delete remote" mode
#4815 Outlook meeting invitations: timezones
#3472 code cleanup + quality improvements + #3476 Klocwork
#2427: attachments in iCalendar 2.0 events/todo
#4774 verify a server's conflict handling policy
#2143 service setting changes should be tested with server right away
#2416 intelligent handling of unexpected slow syncs
#2428 allow aliases for config options (user=username)
#2429 HTTP AUTH
#2432 rewrite synccompare in C++
#3311 libsynthesis: field list <-> XML conversion
#3313 push notification: via email and IMAP IDLE (or XMMP)
#3477 local timezone
#3604 command line: use keyring
#2260 need interface to set useProxy or not
#3471 libsynthesis: better configuration mechanism + debugging
#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.