Subject: Re: Resource passing: from sync plugin to format plugin
Newsgroups: gmane.comp.misc.opensync.devel
Date: 2008-09-13 18:31:27 GMT (42 weeks, 7 hours and 9 minutes ago)
On Monday 08 September 2008 17:02:40 Adenilson Cavalcanti wrote: > I have being working in the gcalendar plugin in the last few months. > Last time I posted here, I got the suggestion from Daniel Gollub to > write a format plugin to do the conversion from gdata > (contacts/calendar) to opensync xmlformat. > > I'm doing the transform from gdata (contact/calendar) to opensync > xmlformat using XSLT. The expensive part in doing that is to read the > style file and create the style context. Ideally, it should be done > only *once* when doing synchronization. > > If I read the style and create the context inside of the converter > callback, its going to be horribly inefficient. Ideally, it should be > created when the plugin was initialized (or connected) only once. > > Using a static variable inside of format plugin converter function is > nasty... and a global (inside of format context) is even worst. > > So the need to pass a resource (the XSLT style context) from sync > plugin to format plugin. > > > Is there a way to do that? Bjoern implemented something similar to avoid parsing of the XML Schema file everytime (i guess this is similar expensive as XSLT parsing). But we're utilizing for this the "internalFormat" inside the engine, and keep a reference for the schema. So this is not really a solution for you... But maybe be we can enhance the format plugin interface a bit and introduce initialize and finalize functions for the format plugins. To avoid overhead by initialize ALL installed format plugins, we should call format-plugin initialize function right before starting converting all entries. And finalize once the conversion is done. This effort is a bit related with the idea of doing conversion-path detection only once, if possible, and apply the same conversion path to all changes/entries. And before and after doing the batch-format-conversion-processing, we call initialize and finalize for involved format plugins. So we have only 1x detect once the conversion path, only have to allocate/parse 1x required data (e.g. XSLT conversion stylesheet, ...) event for 99999999 changes/entries which need to get converted. But all this would require some major changes in the current format conversion processing: 1. detect/create conversion path(es) for all entries in advance 2. call (new) initialize function of all involved format plugins 3. run the format conversion on all entries 4. call (new) finalize function of all involved format plugins Maybe we should introduce format plugin initialize function per converter. Since some format plugins provide several format-converters (A to B, B to A) or even several formats (A to B, A to C, B to A, C to A) - having initialize functions per converter would allow to only parse/allocate the stuff required by the specific converter. E.g.: empty mobile got synced with google calendar plugin - you only have to parse one XSLT from gcalendar to xmlformat-event ... not vice versa. All this would require very likely API change in the format plugin area. I thought about passing a void *userdata pointer as second last argument: typedef osync_bool (* OSyncFormatConvertFunc) (char *input, unsigned int inpsize, char **output, unsigned int *outpsize, osync_bool *free_input, const char *config, void *userdata, OSyncError **error) Thoughts? best reagrds, Daniel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/