6:12 p.m.
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.