Plugin Porting guide 0.2x -> 0.30

• If you haven't done so already, familiarise yourself with all of the new terms/concepts in the glossary and make sure you have built the new Opensync framework, msynctool and at least the file-sync plugin (see trunk/hackingGuide).
• Look at docs/example-plugin for updated example plugin code. You may also find the file-sync plugin useful as a reference.
• The format/conversion and main plugin modules that are part of a plugin now each have a function int get_version(void). At the moment this function must return 1.
• For conversion functions, the void *user_data parameter has been removed, and a const char *config has been added (as the second to last parameter).
• You may have to adjust your #includes in some cases.
• osync_change_new() now takes an OSyncError **error parameter
• For osync_change_set_data(), the last two parameters have been removed and the data parameter is now an OSyncData * (struct containing data, size, etc.)

Plugin initialization

• Plugin format registration has been moved out of the main plugin get_sync_info function (formerly get_info). Formats and converters are each now registered in separate functions. See the example plugin for details.
• Plugin initialization function arguments have changed from:

  OSyncMember* member, OSyncError** error
  

  to:

  OSyncPlugin *plugin, OSyncPluginInfo *info, OSyncError **error
  

• Loading config has changed from:

  	char *configdata = NULL;
  	int configsize = 0;
  	if (!osync_member_get_config(member, &configdata, &configsize, error)) {
  		osync_error_update(error, "Unable to get config data: %s", osync_error_print(error));
  		goto error_free_env;
  	}
  

  to:

  	configdata = osync_plugin_info_get_config(info);
  	if (!configdata) {
  		osync_error_set(error, OSYNC_ERROR_GENERIC, "Unable to get config data.");
  		goto error_free_env;
  	}
  

• You need to register a sink for each object type your plugin handles. Depending on how your target/device works and how you structured your plugin in 0.2x, this may mean splitting up your plugin code a little bit. If you have a general plugin environment struct and then a separate environment struct for the sinks (with a pointer back to the plugin environment struct), you may be able to use the same code for each sink and just have different values in the sink environment for each sink.

Formats

• vformat support has been split out to a separate format plugin which you will need to install

Internal XML formats

• The names of the formats have changed, eg. xml-contact is now xmlformat-contact; xml-event is now xmlformat-event, etc.
• The standard xmlformat-* objformats are now actual objects instead of strings. If you want to deal with the documents as serialised strings only, add the suffix "-doc" to the format name eg. "xmlformat-contact-doc".
• To handle the XML format objects, use the osync_xmlformat_* and osync_xmlfield_* functions. See gnokii_contact_format.c in the gnokii plugin for usage examples.
• The internal XML formats themselves remain largely the same, but there are some minor changes:
  • For contacts, "Type" elements that would have previously translated into vcard TYPE entries have been changed to attributes. Of course you cannot have more than one attribute with the same name, and phone number entries need this (eg. home fax), so they have also been renamed. The "Type" attribute is now for the type of entry (eg. "Voice", "Fax", "Cellular" etc.) and the "Location" attribute specifies the location eg "Home", "Work" etc. Note also that the values have been converted from all upper case to standard case (eg. "VOICE" -> "Voice").
  • Refer to the xmlformat-*.c files in the vformat plugin to see how the XML documents should be structured.