[RFC] Which parameter are required for format conversion?

[Daniel Gollub-3]

Hi,

i'm try to get back into #1084.

Today the conversion function prototype looks like:

osync_bool (*ConvertFunc) (char *input, unsigned int inpsize,
                           char **output, unsigned int *outpsize,
                           osync_bool *free_input,
                           const char *config,
                           void *userdata,
                           OSyncError **error);


This function is used by the format plugins to convert a format A to format B.
The config parameter today (AFAIK) get only used evo2-sync and kdepim-sync to
enable soem extension handling of the vformat plugin:

evolution2/src/evo2-sync:         <Config>VCARD_EXTENSION=Evolution</Config>
kdepim/src/kdepim-sync:          <Config>VCARD_EXTENSION=KDE</Config>

This values (should! - due to a bug this might be wrong) get passed to the
conversion function.

AFAIK all other format plugins don't use the config parameter.

With the advanced use of capabilities information from peers we have to do
more advanced use of some kind of converter configuration.

Some examples:
- deal with format extensions (vendor extensions, KDE, Evolution, ...)
- conversion of certain timestamps: UTC, Localtime
- workaround peer bugs
- overwrite wrong reported peer capabilities
- how many Telephone numbers should be converted?
- which telephone number should be preferred?
- configure generic format plugins (e.g. name of a XSLT conversion stylesheet)
- (If you have more scenarios which require further tweaks/knobs for
conversion please let us know!)


In one of the RFC-Threads about Capabilities there was the idea about passing
OSyncCapabilities pointer to the conversion function parameter-list. To give a
conversion function access to reported capabilities (e.g. Localtime/UTC from
SyncML). But also to do some of the _demerge_ work. (e.g. only convert the
preferred telephone number (if the number limit of peer get exceeded))


So i have now several question to you, sync- and format-plugins developers:

1. Should we drop the demerge function completely from OpenSync. And let the
conversion function of a format-plugin do the "demerge" work? demerge work
consists of: strip all, by the peer unsupported fields - based on peers
configured/reported capabilities
 

2. Allow conversion functions to operate as converter and merger (at the same
time)?

3. Keep merge and conversion operation separated?

4. Would your format plugin benefit if it get OSyncCapabilities* passed as
conversion parameter?

5. Which conversion configuration do you need for your formats?

6. Is there any configuration which needs to be applied on an entire
conversion-path? Or is there only per converter one configuration required?

7. Which capabilities information (related to formats) do you receive from
your peer device/interface?

8. If your capabilities are static configured - which capabilities are
configurable?

9. Are you able to access all capabilities information during the "discover"-
phase?

10. If your plugin is not able the access all capabilities during the
"discovery"-phase - when are the capabilities accessible? During a sync?  
before get_changes? after get_changes?

11. Are capabilities updates of your peer "defined"/possible? Factory reset,
device replaced, ...


Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel