TODO for OpenSync 0.40

libopensync (unsorted):

  • Fix osync_merger_merge() - the result of a merge xmlformat isn't/wasn't sorted. For this reason some ugly workaround got implemented to do sorting of the xmlformat before returning the xmlformat-merged result. Sorting is way to expensive - get rid of this! Review if the merger is still broken, maybe it got fixed meanwhile.... write regression test.
    • moved to ticket #754

  • get rid of osxml_* only make use of osync_xmlfield_* and osync_xmlformat_*
    • no plugins make use of osxml_* anymore.
    • The only osxml_ users are: opensync/merger/opensync_xmlfield.c opensync/merger/opensync_xmlformat.c opensync/version/opensync_version.c
    • moved to ticket #753
  • Clean up OSyncTime
    • Implement Timezone handling for XMLFormat?! moved to ticket #752
  • API Documentation
    • There are still some gaps ... mind the gap.
    • moved to ticket #755
  • remove objformat plain and xmlformat-*-doc [REJECTED]
    • dfriedrich, could you please comment why we should drop xmlformat-$objtype-doc? moto-sync rely on that one...

  • Write unit tests
    • extended merger unittest
      • check for data loss and "slow-sync" conflicts...
      • check if merged result is sorted
    • SlowSync?
      • write unit tests for triggering a SlowSync? for staling group lock file -> locking test got ported
      • check if mapping table got flushed when slowsync got requested, to avoid assert with inconsistent mapping tables
  • time helper API
    • check conversion of different time formats
    • check for correct conversation between UTC and localtime
    • fix broken testcase: time_unix_converters
      • is this test timezone specific?
        • yes, it was, America/Montreal - got fixed with r2747
  • fix python wrapper for x86_64 and ppc
    • isn't this an swig issue?
      • yes, it is. (cstender)
  • osync_mapping_engine_supports_ignore() - fix it.
    • osync_objtype_sink_get_read() can't be used since there seems to be now interface between the plugin and the engine to check if read_func() is avaliable. A possibility would be to store the status of func_read() in the syncmember.conf (during the discover() call) - and reuse this for osync_objtype_sink_get_read(). Or just fix osync_objtype_sink_get_read()!
    • SOLVED: osync_objtype_sink_get_function_*() and ObjTypeSink? marshall function got enhanced to serialize the status of the sink engine functions (read, get_changes, write) - r2564
  • unidirectional sync initial implementation r2563
    • implementation in OSyncSinkEngine and syncmember.conf
    • <write>0</wirte> (syncmember.conf) set to 0 the sink should act as read-only sink
    • unit tests for unidirectional synchronization. check that the "read-only" sink NEVER got touched.
  • merger/demerger
  • capabilities support
  • implemented conflict handler: latest entry
  • osync_member_call_plugin dont work (should we really reimplemented this?! try to avoid un-common APIs?!)
  • Check for memory leaks (valgrind --leak-check=yes ...)
  • setup Doxygen
  • OSYNC_START_TYPE: threading, external, internal, ... (osplugin,...) aka. IPC
    • initial reimplementation r2511
    • everything seems to work expecting the client_shutdown() - the end pipe doesn't got send a HUP signal

MSynctool

  • implement 'one-way' synchronization with filter rules - rejected -> unidirectional sync within OSyncSinkEngine (read-only sink)
  • rename msynctool to opensync and include it in /trunk/tools it's just about wasting time..
  • filter support rejected - write XML by hand - it's a task for a _real_ UI

vFormat Plugin

  • add and fix unit tests
  • fix type parameter handling (e.g. TYPE=INTERNET,PREF)
  • check xsd files and correct 1*DIGIT
  • complete support for VTIMEZONE
  • write reference capability files for the iCalendar, vCalendar, vCard 2.1, vCard 3.0, ... this is needed as reference kdepim-sync, evo2-sync and file-sync reference
  • extended converter tests
    • prepare a set of vcalendar, icalendar and vcards which are breaked the convert in past
  • Object Types
    • Contact
      • finish vcard21 and vcard30 support
      • fix ordering of attributes
      • add support of <Photo> field
      • test and fix inline binaries (sound, photo, etc)
    • Event
      • review XML scheme
      • fix ordering of attributes
      • fix handler for correct vcal10/vcal20 conversion
      • fix alarm, timezone, rrule and exrule xml to vcal handler
    • Todo
      • review XML scheme
      • add missing handler
      • fix ordering of attributes
    • Note
      • review Note XML scheme
      • write XML-Note - vnote converter

Device-Plugins

  • gnokii
    • porting to 0.30 API
    • capabilities support ticket #760
  • palm
    • porting to 0.30 API (ongoing by jerryyu)
    • capabilities support ticket #762
  • syncml
    • porting to 0.30 API
    • capabilities support ticket #761
  • opie
    • porting to 0.30 API
    • bugfixes
    • capabilities support ticket # 763

PIM Plugins:

  • evolution2
    • porting to 0.30 API
    • capabilities support ticket #764
  • kdepim
    • porting to 0.30 API
    • capabilities support ticket #765
    • option for resource selection - only the default resource isn't that nice... ticket #766

Service Plugins:

  • file-sync
    • capabilities support
      • select the full capability set of the selected objformat
    • porting to 0.30 API
    • object format "file" means data dump (binary) syncing - rejected
      • to dump data - just disable the converters
    • enhance file-sync with configuration node "objformat" to define the target object format to store
    • object format "file" is default and makes data dump of change - rejected
      • objformat format "file" is default - but you have to disable the converter to do real data dump
  • porting python-module wrapper

TODO for OpenSync > 0.40

TODO: Review and add some of these features to OpenSync? 0.40 TODO

libopensync (unsorted):

  • dynamic xsd query for plugins
    • Should we really target this for 0.40? - dgollub
  • filter support
    • Did anyone use this in 0.2X?! Should we skip this and do a nice implementation after 0.40? (dgollub)
  • no limit of XMLField levels
  • merging of XMLField attributes - use case: categories
    • attributes which shouldn't by synced (e.g.: UI-Slot(?))
    • attributes which never will be the same ... unique data like specific datestamps or member specific UID
  • Slave Engine (syncing OpenSync instance with OpenSync instance, SyncML HTTP Client, ...)
    • very stupid and simple engine without conflict handling
    • changing the order of commands (get_changes, commit, ...)

vformat (unsorted):

  • Add support for VJOURNAL, VFREEBUSY