[
https://issues.apache.org/jira/browse/SLING-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870529#comment-13870529
]
Marius Petria commented on SLING-3315:
--------------------------------------
[~bdelacretaz] another potential issue with directly accessing the
configuration files is the tight coupling of a client with the instance
settings (maybe it is the same point [~fmeschbe] presented but I wanted to give
an example bellow).
For example there are various paths where the configs can be installed (config,
config.author). Also the new configs are created in a distinct location, all
these can be configured in the Sling JCR installer. Moreover, it appears also
that new configs are stored as plain files rather than sling:osgiconfig nodes.
Basically, it will be quite tedious, even if possible, for a client application
to discover all the instances created from a certain factory. It will need to
contain logic to distinguish between runmodes, i.e. to consider only those that
apply to the current instance, and also logic to distinguish between the types
of the config files.
In general it will be nice to have a way to automatically allow exposing
certain types of configuration to certain users, but this does not seem to be
the case now.
Regarding our approach, do you think we should go on with this patch or focus
on implementing config access generically?
> Refactor replication HTTP API
> -----------------------------
>
> Key: SLING-3315
> URL: https://issues.apache.org/jira/browse/SLING-3315
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Marius Petria
> Labels: replication
> Attachments: SLING-3315.patch
>
>
> Refactor HTTP API in order to access independently the configuration of an
> agent and the service API for an agent. This was needed because there are
> times when a configuration can exist without an agent being available (e.g.
> when the agent is not disabled).
> Proposed API:
> Managing configuration
> POST /system/replication/config/agent (creates and agent cofig)
> GET /system/replication/config/agent (retrieves all agents config)
> POST /system/replication/config/agent/{agentName} (updates and agent)
> GET /system/replication/config/agent/{agentName} (retrieves the agent
> config)
> DELETE /system/replication/config/agent/{agentName} (deletes an agent config)
> Managing agent
> POST /system/replication/config/agent/{agentName} (schedules a package
> for replication or removes one from the queue)
> GET /system/replication/config/agent/{agentName}/queue (lists the
> packages in the queue)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
