Ticket #1013 (new enhancement)

Opened 6 years ago

Last modified 4 years ago

Separate static and dynamic parts of plugin/member configuration

Reported by: henrik Owned by: dgollub
Priority: high Milestone: OpenSync 0.40
Component: OpenSync: Application API Version: 0.38
Severity: critical Keywords:
Cc: henrik@…, dgollub

Description

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

Change History

comment:1 Changed 6 years ago by dgollub

  • Severity changed from normal to critical

Bumping severity to not slip for 0.39 milestone.

comment:2 Changed 6 years ago by dgollub

  • Component changed from OpenSync to OpenSync: Application API

comment:3 Changed 6 years ago by dgollub

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

comment:4 Changed 5 years ago by dgollub

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

comment:5 follow-up: ↓ 9 Changed 5 years ago by 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

comment:6 Changed 5 years ago by 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

comment:7 Changed 5 years ago by 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

comment:8 Changed 5 years ago by 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.

comment:9 in reply to: ↑ 5 Changed 5 years ago by dgollub

  • Owner changed from henrik to dgollub
  • Status changed from new to assigned

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 ...

comment:10 Changed 5 years ago by dgollub

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

refs #1013

comment:11 Changed 5 years ago by dgollub

  • Cc dgollub added
  • Priority changed from normal to high
  • Status changed from assigned to new
  • Milestone changed from OpenSync 0.39 to OpenSync 0.40

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

comment:12 Changed 4 years ago by 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

Note: See TracTickets for help on using tickets.