Make OSyncCapabilities and the use of Merger/Demerge format independent

[dgollub]

To avoid that the OSyncCapabilties interface and the MErger/Demerge gets dependent on one single format (e.g. XMLFormat) we should make this more future proof and prepare that it's possible to have sevearl "common formats" like xmlforamt.

So it's easier to switch away from XMLFormat if there is a better alternative one day.

To be clear: Currently there is no alternative to XMLFormat! Keep going with XMLFormat - but don't make yourself depending on it inside your sync plugin!

Some initial notes have been made on http://www.opensync.org/wiki/trunk/features/mergerCapabilities Also helpful: http://www.opensync.org/wiki/trunk/features/mergerFormatConversion

[dgollub]

 http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787

[dgollub]

Initial API desgined for OSyncFormatMerger and changes on OSyncCapabilites and retgister interface for OSyncFormatEnv - stil NOOP

[dgollub]

Proposal from Patrick Ohly:

Drop the separate merger/demerger concept. Move that functionality into
the format conversion.

When converting towards OpenSync, the format plugin works with an item
in the "foreign", limited format, a capabilities description that
describes the format used by the peer, and a complete item in the
internal format. The result is an updated internal item with information
from the peer mixed in, or a complete copy of the incoming item when
there is no internal item yet.

When sending towards a peer, the format plugin only needs to pick
properties from the internal item according to the peers capabilities.
"Only read what you need" looks more natural to me than the current
concept of "strip an item, then convert the stripped down version". The
additional advantage is that this conversion has full access to all
available information, which may be an advantage when going beyond a
static capabilities-based conversion towards a scripted one which also
uses dynamic configuration.

 http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787/focus=3800

[dgollub]

Initial implementation of a combied conversion-merge function which get capabilities and archive_data passed

[dgollub]

Next:

• porting file-sync
• porting xmlformat plugin
• porting vformat plugin
• test file-sync <-> file-sync group with vcard21 and vcard30 and different caps

[bricks]

If I understand the new approach correctly it contains a problem with the conversion path. The capabilities have to be used only at the edges of the conversion path towards the sync plugins. E.g. if you have a path like

syncplugin1<->formatA<->commonformat<->formatB<->formatC<->syncplugin2

formatA and formatC are at the edges. FormatB can ignore the capabilities. Therefore who decides (and when) a format has to use the capabilities within the conversion.

[dgollub]

Replying to bricks:

If I understand the new approach correctly it contains a problem with the conversion path. The capabilities have to be used only at the edges of the conversion path towards the sync plugins. E.g. if you have a path like

syncplugin1<->formatA<->commonformat<->formatB<->formatC<->syncplugin2

formatA and formatC are at the edges. FormatB can ignore the capabilities. Therefore who decides (and when) a format has to use the capabilities within the conversion.

Björn, thanks pointing this out!

I would say we could handle this inside osync_format_env_convert().

This function knows the conversion path - and could determine if it's on the edge. Actually you have to see this conversion chain as two separated paths!

1. formatA <-> commonformat
2. formatC <-> commonformat

Also see the diagrams at (ignore merge/demerge) http://www.opensync.org/wiki/trunk/features/mergerFormatConversion

[dgollub]

This was the last mail on the discussion:  http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787/focus=3818

I try to look into this this week - sorry for not being more active the last days.

[dgollub]

(In [5652]) Add initial draf of capabilties XML Schema for internal storage of capabilities information

refs #1084

[dgollub]

(In [5653]) First set of OSyncCapability getter interface. Without any function yet - just the interfaces.

refs #1084

[dgollub]

(In [5654]) Added more OSyncCapabilities and OSyncCapabilitesParameter interfaces (_setter)

refs #1084

[dgollub]

(In [5655]) Dropped more obsolate OSyncCapabilities Interfaces

refs #1084

[dgollub]

(In [5656]) Adapt python wrapper to api changes Only dropped missing interface from wrapper. TODO: wrap new interfaces

refs #1084

[dgollub]

(In [5657]) Splitted osync_capabilitiesobjtype_new() into osync_capabilitiesobjtype_new() and osync_capabilitiesobjtype_new_node(). Later one is for internal use only, parsing the XML document. First one is for assembling capabilities from plugin space.

refs #1084

[dgollub]

(In [5658]) Adapted testcase capability_new Dropped capabilities_sort

• new OSyncCapabilities object will work on a sorted list
• list_insert_sorted()

refs #1084

[dgollub]

(In [5659]) Adapted test fixues for capabilities_parse to new capabilities schema.

refs #1084

[dgollub]

(In [5662]) Move member related capabiliteis functions to opensync_member. TODO: rename interfaces (doesn't hurt just used internally)

refs #1084

[dgollub]

(In [5663]) Rename internal member capabilities interfaces to fit the OSyncMember namespace

refs #1084

[dgollub]

(In [5664]) Add missing symbol entry

refs #1084

[dgollub]

(In [5665]) Split OSyncCapabilitiesObjType and OSynCapabilites

refs #1084

[dgollub]

(In [5666]) Initial parsing of a capbility node.

refs #1084

[dgollub]

(In [5667]) Fix build of testsuite.

refs #1084

[dgollub]

(In [5670]) Initial code for assemble and parsing capabilities

refs #1084

[dgollub]

(In [5676]) Fixed assembling and parsing of new capabilities interface

refs #1084

[dgollub]

(In [5677]) Added interfaces and tests to save and load capabilities as file

refs #1084

[dgollub]

(In [5679]) Dropped assemble/prase interface from OSyncCapabilities API osynctool requries porting. Applications must not have direct access to edit the internal stored format (e.g. XML editing via editor)

refs #1084

[dgollub]

(In [5681]) Exported osync_capabilities_objtype_new to public API. For plugin discovery function

refs #1084

[dgollub]

(In [5682]) Add missing parsing of the CapsFormat? name

refs #1084

[dgollub]

On some call Daniel Friedrich came up with a solution to still work with one merger - but still kepp the capabilities independent:

• still a generic way to store native capabilties is required (see #1084 branch)
• move translation(-tables) from the sync-plugin into a tiny format-plugin
• the tiny format plugin has the possibilty to get called with specific capabilities-translator function - for a specific format (function register per format)
• this makes the sync-plugin independent of common formats

WIP: PoC for evo2-sync and syncml-obex-client

[dgollub]

Discussion with Björn Ricks at Linux Tag. For multi-capabilities-format support we do follwoing introductions:

• merge/demerge objformat registrion get extended with "capsformat"
  • so merger/demrege get registed with a objformat/capsformat tuple
  • + OSyncMerger *osync_merger_new(const char *objformat, const char *capsformat, OSyncError error)
  • + osync_format_env_register_merger(OSyncFormatEnv *, OSyncMerger *)
  • - osync_objformat_set_{,de}merge_func()
  • Struktur OSyncMerger
    • int ref_count
    • char *capsformat
    • char *objformats
    • init_func/fainlize_func
• objformat get a new format plugin function called "caps_converter"
  • osync_bool (* caps_converter) (OSyncCapabilities *old, OSyncCapabilities new, OSyncError error)

[bricks]

(In [5698]) Introduced API changes from Linuxtag discussion about Mergers Currently the new API is only defined and not implemented refs #1084

[bricks]

(In [5699]) added new merger api refs #1084

[bricks]

(In [5700]) implemented first parts of merger api refs #1084

[dgollub]

(In [5720]) Merged ticket #1084 branch

To speed up trunk development

refs #1084

[dgollub]

(In [5721]) Drop ticket1084 branch. Development for #1084 continous in /trunk

refs #1084

[dgollub]

(In [5728]) Quick and dirty porting to latest libsyncml-trunk. Disabled capabilities related code, due to heavy api changes. See #1084

[dgollub]

Replying to dgollub:

Discussion with Björn Ricks at Linux Tag. For multi-capabilities-format support we do follwoing introductions:

• merge/demerge objformat registrion get extended with "capsformat"
  • so merger/demrege get registed with a objformat/capsformat tuple

done

• + OSyncMerger *osync_merger_new(const char *objformat, const char *capsformat, OSyncError error)

done

• + osync_format_env_register_merger(OSyncFormatEnv *, OSyncMerger *)

done

• - osync_objformat_set_{,de}merge_func()

got dropped, done

• Struktur OSyncMerger
  • int ref_count
  • char *capsformat
  • char *objformats
  • init_func/fainlize_func

done

Additionally

• merger_func
• demerger_func

got added.

• objformat get a new format plugin function called "caps_converter"
  • osync_bool (* caps_converter) (OSyncCapabilities *old, OSyncCapabilities new, OSyncError error)

TODO - going to open for this last item a seperated ticket ... this one is getting to heavy.

[dgollub]

Last item got handled in #1146