Separate static and dynamic parts of plugin/member configuration

[henrik]

As agreed on OpenSync IRC Meeting, 2008-12-30T14:00:00Z

Currently the member configuration file (e.g. .opensync/groupX/Y/xxx.conf) contains two different things:

• Definitions of the AdvancedOptions then plugin accepts
• Values for the AdvancedOptions, Connection, and Resources for the specific member

This should be split into:

• A static configuration file containing the AdvancedOptions then plugin accepts (stored read-only in a distro dir)
• A dynamic configuration file containing the values set for the specific member (stored in .opensync/groupX/Y/xxx.conf).

As this is kind of a design issue, discussion about this should take place on the opensync-devel list

/Henrik

[dgollub]

Bumping severity to not slip for 0.39 milestone.

[dgollub]

Henrik, did you managed to write initial code for this? I wonder if we shout keep this for 0.39 milestone

[dgollub]

I still wonder if we should keep this for 0.39....

[dgollub]

I reviweed this briefly with regard to API changes. In short: API changing/breaking is required.

Things TODO:

• define in build-env the read-only distro-install dir for static configuration so plugins can use it as CMAKE-variable
• declare this CMAKE-variable in config.h.cmake template for internal declartion
• adapt osync_plugin_config_load()
  • remove schemadir param
• add osync_plugin_config_set_schemadir(OSyncPluginConfig*, const char *path) (for unittesting)
  • if not called the defined default path get used
• add osync_plugin_config_set_advanceddir(OSyncPluginConfig*, const char *path) (for unittesting)
  • if not called the defined default path get used
• add to XSD of plugin_config a <File/> field which defines the static advananced config filename (not path!) to load
• osync-plugin_config_load() needs to assmble the path to the static advnaced config file from the <File/> field aand the defined _advanancddir parameter.
• Split pluing_config into XSD Definitions of AdvancedOptions (advanced_plugin_config.xsd) and the vvalues (plugin_config.xsd)
• adapt code of _osync_plugin_config_{parse,assemble}_advancedoption() to deal with the definition and the value files

For 0.39 i would suggest to jsut schedule the API breaking part:

• adapt osync_plugin_config_load()
  • remove schemadir param

• add osync_plugin_config_set_schemadir(OSyncPluginConfig*, const char *path) (for unittesting)
  • if not called the defined default path get used

[dgollub]

Discussion with Henrik on IRC.

For now we do do dynamic location of AdvancedConfigs?. Instead a fixed config of the plugin get loaded. This means the <File/> is gone.

Additional API addition:

• add osync_plugin_config_set_advancedconfigdir(OSyncPluginConfig*, const char *path) (for unit testing)
  • if not called the defined default path get used

[henrik]

I have not looked into the API, so I cannot comment on that. However, here are some comments on the principle and file formats...

Principle:

1. The plugin should be in total control over which AdvancedOptions can be set. Those should be defined in a static config file at install time
2. The user/frontend/GUI should be in control over the value of each option. Those should be defined in a dynamic config file in the user's .opensync/groupX/Y directory.
3. At runtime the OpenSync trunk should read the static config file and merge the values from the dynamic config file into this (with error checking).

File formats

1. The static config file could have an XSD like the one we have today. <Value /> settings would be treated as default values.
2. The dynamic config file could look like this:

   <AdvancedOption name="WBXML">1</AdvancedOption>
   <AdvancedOption name="SANVersion">1.1</AdvancedOption>
   <AdvancedOption name="ATCommand"></AdvancedOption>
   <AdvancedOption name="Identifier">PC Suite</AdvancedOption>
   ...
   

Further topics

1. <Connection> and <Resources> should be treated similar to the above.
2. I propose that the dynamic config file has the name of the AdvancedOption as an attribute to the <AdvancedOption> tag. It would probably make sense to make the same change in the static config file to keep them "similar".
3. We also need internationalized lead texts, tooltip texts, help texts, etc. However, I do believe that those cold be added alter in separate locale-specific files.
4. The <ActiveConnection> is a mess. See ticket #1011.
5. We might want to have some pre-defined dynamic config files. Eg. for syncml it would make sense to have one per phone model. For now, the frontend/GUI could keep track of those, but for the future we need a way to share such pre-defined dynamic config files between different frontend/GUI's using the same plugin

[henrik]

One more thing: In a plugin config we have e.g.:

  <Resources>
    <Resource>
      <Enabled>1</Enabled>
      <Formats>
        <Format>
          <Name>vcard21</Name>
        </Format>
      </Formats>
      <Name>Contacts</Name>
      <ObjType>contact</ObjType>
    </Resource>
  </Resources>

So, a plugin can define which resources it supports, and a frontend can enable/disable those. But what about formats? The above is from SyncML. But SyncML supports also vcard30. It should be possible to define the formats a plugin supports in the static part of the configuration.

[dgollub]

Replying to dgollub: [...]

For 0.39 i would suggest to jsut schedule the API breaking part:

• adapt osync_plugin_config_load()
  • remove schemadir param

• add osync_plugin_config_set_schemadir(OSyncPluginConfig*, const char *path) (for unittesting)
  • if not called the defined default path get used

Assiging the 0.39 blocking stuff to myself ...

[dgollub]

(In [5765]) Break trunk API by dropping schemadir parameter from osync_plugin_config_load_file()

refs #1013

[dgollub]

No API-breaking-related changes left - move this task to 0.40 milestone

[sim]

​decoration Changed 1 year ago by admin

​bathtub Changed 1 year ago by admin

​solar system Changed 1 year ago by admin

​stair parts Changed 1 year ago by admin

​solar supply Changed 1 year ago by admin