Subject: OpenSync API - OSyncObjFormatSink and other ongoing stuff...
Date: Sunday 4th May 2008 21:18:40 UTC (over 9 years ago)
Hi, just committed major changes in the Object Format handling. Those changes are required to have later a proper implemention of OSyncPluginRessource, a generic plugin interface to handle different ressource. This is one of the last missing pieces of the PluginConfigXsd, the common plugin configuration schema: http://opensync.org/wiki/PluginConfigXsd Please stay with r3307 for some more hours if you're doing some serious development. Since everything beyond r3307 requires changes on every OpenSync Plugins and Frontends. Luckily those changes will make soon lots of redundant code in plugins completed obsolete. So porting to the final changes will turn out in pressing your delete key more often then your Return key ;) Plugin Developers: Most of the reporting of available OSyncObjTypeSink and which OSyncObjFormat are supported (which is done within the plugin initialize funcition), will be done on the fly on the OpenSync engine side. Since the generic configuration will allow this features. You might have to add some lines code in your plugin discovery function, which have to be done anyway. If you have a look on OpenSync 0.40 TODO list: http://opensync.org/wiki/TODO .. most of the oustanding stuff is about the capabilities support which should be handled in the plugin discovery function. More information about this later... Frontend Developers: Please have a look on http://opensync.org/wiki/PluginConfigXsd and check the OSyncPluginConfig interface, it's planned to switch to them very soon. I'll prepare a reference implemention for msynctool within the next days. The advantages: - you don't have to parse XML on your own - plugin config is specified and will be (hopefully!) used by all plugins soon - maybe it's even possible to write generic UI widgets, so you don't have to create a new one for each new plugin Some oustanding implemention details to discuss, about configuration files and other files within the members directory. Right now we have: syncmember.conf $plugin.conf Since even $plugin.conf is specified and with OSyncPluginRessource there is some redundant information in both configs. Are there any objections to have another file to avoid this redundant information? So far i have "ressource" information in mind. Which basically is about the per ressource information: - Ressource identifier (e.g. database name, path, url, ...) - ObjFormat(Sink) and Object Type - Active Ressource (to sync or not to sync?!) Does anyone see an advantage/disadvantage to move this information completely into syncmember.conf or $plugin.conf - or an compeltely different file? (Later would require some more effort to make the "updater" aware of a 4th kind of special file - syncgroup.conf, syncmember.conf, $plugin.conf, NEW: ressource.conf .... best regards, Daniel ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone