Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Daniel Gollub <dgollub <at> suse.de>
Subject: OpenSync API - OSyncObjFormatSink and other ongoing stuff...
Newsgroups: gmane.comp.misc.opensync.devel
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
 
CD: 3ms