Menu
▾
▴
opensync-devel
|
From: Henrik /K. <he...@ka...> - 2009-11-09 18:08:45
|
Dear all, A member of a group has a configuration file. The default configuration file comes from the plugin. E.g. http://opensync.org/browser/plugins/mozilla-sync/trunk/src/mozilla-sync Frontends may use the default configuration file to show a nice GUI. This could include GUI for AdvancedOptions, and GUI for selecting specific Resources. Would it be possible to implement some mechanism, which would allow us to have more than one default configuration file per plugin? This would make sense, if different versions of a plugin supports different AdvancedOptions, different Resources, etc. In particular, it would make a lot of sense for external plugins, where the OpenSync SVN only contains configuration files, but the actual code is hosted, build and distributed somewhere else. Several different default configuration files could be included in OpenSync, and OpenSync could select the appropriate configuration file depending on the actual external plugin version. As an example: Future versions of mozilla-sync may support only vformat, whereas the current version supports xml-format. It would be great if OpenSync could carry different configuration files for this, and select the correct one depending on the actual blueZync it is connecting to. I could of course create just one default configuration file with both Formats, but a GUI would not be able to figure out that this particular version of the external plugin will only support one of them. Daniel has already described how this is done for capabilities. See http://old.nabble.com/xml-file-with-capabilities-td25978588.html I was wondering if we could do something similar for the default configuration file. As far as I can see, the challenge is, that the capabilities file is read AFTER discover, and it is discover which sets the version information used to select the appropriate capabilities. On the other hand, the default capabilities file would be needed BEFORE discover. I have never figured out what the plugin's get_version is used for. Could it be used here? Any comments on this would be most appreciated. /Henrik |
|
From: Jakub M. <ja...@o2...> - 2009-11-10 20:56:44
|
Some comments from the "beginner's" point of view: > Frontends may use the default configuration file to show a nice GUI. > This could include GUI for AdvancedOptions, and GUI for selecting > specific Resources. > > Would it be possible to implement some mechanism, which would allow us > to have more than one default configuration file per plugin? I guess there can be only one "default" file ;) Isn't it possible for the GUI to use only the necessary options from all that are declared in the file? > As an example: Future versions of mozilla-sync may support only vformat, > whereas the current version supports xml-format. > It would be great if OpenSync could carry different configuration files > for this, and select the correct one depending on the actual blueZync it > is connecting to. > > I could of course create just one default configuration file with both > Formats, but a GUI would not be able to figure out that this particular > version of the external plugin will only support one of them. Maybe, as a temporary solution, just make thin new version of a plugin exist as a new plugin, with another configuration file. Then, there's no need to change the Opensync logic. Does it make any sense? > I have never figured out what the plugin's get_version is used for. > Could it be used here? This is a good point. I found a statement: "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. " Is this "MUST" still so importart? Bloosky ja...@o2... |
|
From: Daniel G. <go...@b1...> - 2009-11-12 09:21:55
|
On Tuesday 10 November 2009 09:56:22 pm Jakub Marczynski wrote:
> > I could of course create just one default configuration file with both
> > Formats, but a GUI would not be able to figure out that this particular
> > version of the external plugin will only support one of them.
>
> Maybe, as a temporary solution, just make thin new version of a plugin
> exist as a new plugin, with another configuration file. Then, there's no
> need to change the Opensync logic. Does it make any sense?
Right. The "thinest" way is to build a OSyncPlugin* and register it with
osync_plugin_env_register_plugin()!
>
> > I have never figured out what the plugin's get_version is used for.
> > Could it be used here?
>
> This is a good point. I found a statement:
> "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. "
> Is this "MUST" still so importart?
Yes, check:
---8<---
osync_bool osync_module_check(OSyncModule *module, OSyncError **error)
{
int version = 0;
[...]
version = osync_module_get_version(module);
[...]
if (version != OPENSYNC_PLUGINVERSION) {
osync_error_set(error, OSYNC_ERROR_GENERIC, "Plugin API
version mismatch. Is: %i. Should %i", version, OPENSYNC_PLUGINVERSION);
----->8---
One day we might can use this to support several plugins which are
build/designed against different OpenSync plugins APIs.
Maybe we should introduce some #define instead of a confusing "return 0" ...
something like: return OSYNC_PLUGIN_SYNC_API_VERSION_1;
What do you think?
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: go...@b1... 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
|
|
From: Daniel G. <go...@b1...> - 2009-11-12 08:50:32
|
On Monday 09 November 2009 07:08:32 pm Henrik /KaarPoSoft wrote:
[...]
>
> I have never figured out what the plugin's get_version is used for.
> Could it be used here?
Close, try get_sync_info(). get_sync_info() get called when all the plugins
get loaded:
e.g. osynctool --listplugins
Perfect example would be the SyncML plugin. It's registering 4 plugins in one
get_version() call...
You do this with osync_plugin_env_register_plugin() or so ...
Just set different names for the plugins, then you can have several default-
configuration, due to the different plugins names.
Example:
------8<-----
osync_bool get_sync_info(OSyncPluginEnv *env, OSyncError **error)
{
OSyncPlugin *plugin;
plugin = osync_plugin_new(error);
if (!plugin)
goto error;
osync_plugin_set_name(plugin, "syncml-http-server");
osync_plugin_set_longname(plugin, "SyncML over HTTP Server");
osync_plugin_set_description(plugin, "Plugin to synchronize with
SyncML over HTTP");
osync_plugin_set_initialize(plugin, syncml_http_server_init);
osync_plugin_set_finalize(plugin, finalize);
osync_plugin_set_discover(plugin, syncml_http_server_discover);
if (!osync_plugin_env_register_plugin(env, plugin, error))
goto error;
osync_plugin_unref(plugin);
plugin = osync_plugin_new(error);
if (!plugin)
goto error;
osync_plugin_set_name(plugin, "syncml-http-client");
osync_plugin_set_longname(plugin, "SyncML over HTTP Client");
osync_plugin_set_description(plugin, "Plugin to synchronize with
SyncML over HTTP");
osync_plugin_set_initialize(plugin, syncml_http_client_init);
osync_plugin_set_finalize(plugin, finalize);
osync_plugin_set_discover(plugin, syncml_http_client_discover);
if (!osync_plugin_env_register_plugin(env, plugin, error))
goto error;
osync_plugin_unref(plugin);
return TRUE;
error:
return FALSE;
}
----8<---
This is registering two plugins, which have two different dfeault-
configuration: syncml-http-client and syncml-http-server.
In the case of the SyncML plugin those plugins just differ in the plugin init
function and discover function.
>
> Any comments on this would be most appreciated.
[...]
This is what i try suggested some weeks ago to spawn several plugins for the
mozilla-sync to avoid that user have to set the external_command by their own.
It's just about registering some OSyncPlugin* to OSyncPluginEnv ... even if
those are the same shared-module or so.
Hope this helps.
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: go...@b1... 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
|
|
From: Juha T. <Juh...@ik...> - 2009-11-12 09:49:52
|
On Mon, 9 Nov 2009, Henrik /KaarPoSoft wrote: > A member of a group has a configuration file. > > Would it be possible to implement some mechanism, which would allow us > to have more than one default configuration file per plugin? > > This would make sense, if different versions of a plugin supports > different AdvancedOptions, different Resources, etc. Correct me if I'm wrong, if I say that: - the file is in XML format - X in XML stands for eXtensible - tools reading the XML don't care about stuff they don't understand. - thus the XML, the configuration file is always backwards compatible? - thus the same file can be used regardless of versions? br, Tuju -- Ajatteleva ihminen tarvitsee unta. |
|
From: Henrik /K. <he...@ka...> - 2009-11-12 15:37:33
|
Juha Tuomala wrote: > On Mon, 9 Nov 2009, Henrik /KaarPoSoft wrote: >> A member of a group has a configuration file. >> >> Would it be possible to implement some mechanism, which would allow us >> to have more than one default configuration file per plugin? >> >> This would make sense, if different versions of a plugin supports >> different AdvancedOptions, different Resources, etc. > Correct me if I'm wrong, if I say that: > - the file is in XML format > - X in XML stands for eXtensible > - tools reading the XML don't care about stuff they don't understand. > - thus the XML, the configuration file is always backwards compatible? > - thus the same file can be used regardless of versions? The challenge is not so much the syntax. Even the schema is the same for all plugin configuration files. And a Frontend would probably let the OpenSync library do the parsing anyway. The challenge I am thinking of is this: How can a Frontend present a nice GUI to configure ANY OpenSync plugin? Maybe I am wrong, but the way I do it in blueZync is to look at the advanced options and creating GUI for those, and look at the resources and create GUI for the resources defined in the default config file. Obviously a Frontend may have specific knowledge of specific plugins and create an even better GUI, but it would be nice if a Frontend could automatically create a GUI for any OpenSync plugin automatically. /Henrik |
|
From: Chris F. <cd...@fo...> - 2009-11-13 22:48:30
|
On Thu, Nov 12, 2009 at 04:37:21PM +0100, Henrik /KaarPoSoft wrote: > Obviously a Frontend may have specific knowledge of specific plugins and > create an even better GUI, but it would be nice if a Frontend could > automatically create a GUI for any OpenSync plugin automatically. How is it possible to create a GUI for any plugin at the moment? What if there are plugin-specific fields? How do you label them or describe them in the GUI? Would this have anything to do with these points: Subject: Config's AdvancedOption XML entity: Help? http://sourceforge.net/mailarchive/forum.php?thread_name=20090221040116.GA15434%40foursquare.net&forum_name=opensync-devel Subject: localization in plugin configs http://sourceforge.net/mailarchive/forum.php?thread_name=20091003014003.GA7477%40foursquare.net&forum_name=opensync-devel - Chris |
|
From: Henrik /K. <he...@ka...> - 2009-11-16 19:35:10
|
Chris Frey wrote: > On Thu, Nov 12, 2009 at 04:37:21PM +0100, Henrik /KaarPoSoft wrote: > >> Obviously a Frontend may have specific knowledge of specific plugins and >> create an even better GUI, but it would be nice if a Frontend could >> automatically create a GUI for any OpenSync plugin automatically. >> > > How is it possible to create a GUI for any plugin at the moment? > What if there are plugin-specific fields? How do you label them or > describe them in the GUI? > > blueZync is actually doing this at the moment. Far from perfect, but a start. See attached screenshots. The frontend simply creates a GUI based on advanced options and resources. > Would this have anything to do with these points: > > Subject: Config's AdvancedOption XML entity: Help? > http://sourceforge.net/mailarchive/forum.php?thread_name=20090221040116.GA15434%40foursquare.net&forum_name=opensync-devel > > Subject: localization in plugin configs > http://sourceforge.net/mailarchive/forum.php?thread_name=20091003014003.GA7477%40foursquare.net&forum_name=opensync-devel > Those would improve the GUI which could be presented. /Henrik |
|
From: Henrik /K. <he...@ka...> - 2009-11-12 15:27:16
|
Daniel Gollub wrote: > [...] > Close, try get_sync_info(). get_sync_info() get called when all the plugins > get loaded: > > e.g. osynctool --listplugins > > Perfect example would be the SyncML plugin. It's registering 4 plugins in one > get_version() call... > > [...] > > This is what i try suggested some weeks ago to spawn several plugins for the > mozilla-sync to avoid that user have to set the external_command by their own. > > It's just about registering some OSyncPlugin* to OSyncPluginEnv ... even if > those are the same shared-module or so. > Thank you very much for the explanation! I am aware that I can create several plugins; but I was thinking that maybe there was a way to version plugins / plugin configurations. But from the answer I understand that this is not the case, so I will just create two plugins (the new one probably named mozilla-sync-3). (As mozilla-sync is now a pure external plugin it will be with two xml files, not get_sync_info() ). /Henrik |
|
From: Daniel G. <go...@b1...> - 2009-11-12 15:35:43
|
On Thursday 12 November 2009 04:27:04 pm Henrik /KaarPoSoft wrote: > I am aware that I can create several plugins; but I was thinking that > maybe there was a way to version plugins / plugin configurations. > Oh i see .. i missudnerstood your initial topic. I haven't thought about that yet. I guess thats not a problem we should concentrate on today .. .maybe we should first get something which actually makes syning work and then talk about handling different versions. But what we have - what is maybe interesting for your "problem" ... we have the OSyncUpdater which updates old configs to new configs, with the help of XSLT conversion stylesheets. Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Henrik /K. <he...@ka...> - 2009-11-12 15:51:14
|
Daniel Gollub wrote: > On Thursday 12 November 2009 04:27:04 pm Henrik /KaarPoSoft wrote: > >> I am aware that I can create several plugins; but I was thinking that >> maybe there was a way to version plugins / plugin configurations. >> > > Oh i see .. i missudnerstood your initial topic. I haven't thought about that > yet. I guess thats not a problem we should concentrate on today .. .maybe we > should first get something which actually makes syning work and then talk > about handling different versions. > I have created ticket 1189 so we don't forget... /Henrik |
Thanks for helping keep SourceForge clean.
X