You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2013/11/05 19:55:19 UTC

[jira] [Commented] (SLING-3223) Donation of a replication module for Sling

    [ https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814130#comment-13814130 ] 

Tobias Bocanegra commented on SLING-3223:
-----------------------------------------

some quick comments:
- way to little documentation (javadoc, general architecture)
- Don't use HTTP headers to transport additional information. this makes it harder to get request correctly though proxies and firewalls
- If you use customer HTTP headers, it's best practice to prepend an app specific prefix, eg: {{X-Sling-Replication-Action}}.
- why do you expose  a {{ReplicationConfigurationServlet}} and not rely on default mechanisms to update config, e.g. update the config via SlingPostServlet or via felix console? (Is there some functionality missing in Sling or does every component needs to provide it's own management REST API?)
- {{ReplicationActionType}} names are probably coming from Adobe's replication - I would reconsider if _Activate_ and _Deactivate_ really are good names. btw: how is _deactivate_ implemented? not via an empty content package?
-- alternative names for activate: "add", "put", "import", "post"
-- alternative names for deactivate: "delete"
- I don't know if {{TriggerPathReplicationRule}} is really a sufficient filter. Usually it's hard to determined at what point a modified subtree is ready to replicate. you would probably need to add much more logic to it
- I don't quite understand {{AuthenticationHandler}}. Are those providers that are used to add authentication to the HTTP requests, or are they consumers that are used to authenticate replication payloads?
-- If the first, I would rename them to something more specific, like: {{ReplicationCredentialsProvider}}
-- If the latter, I would really not reinvent the wheel here, and rely on authentication already present in Sling.
- the adapter from {{SlingRequest}} to {{ReplicationPackage}} is really questionable in IMO. It is used in a very specific case and the adaption is considerably expensive. Or do you foresee that other clients of this API adapt a request to a ReplicationPackage ?
- suggest to add package-info.java files with the bundle export information over <Export-Package> elements in the pom.xml





> Donation of a replication module for Sling
> ------------------------------------------
>
>                 Key: SLING-3223
>                 URL: https://issues.apache.org/jira/browse/SLING-3223
>             Project: Sling
>          Issue Type: Task
>          Components: Extensions
>            Reporter: Tommaso Teofili
>         Attachments: SLING-3223.patch
>
>
> Issue to track donation of a replication module for Sling, see thread at http://markmail.org/thread/ic62k5pc34ppb5ko 



--
This message was sent by Atlassian JIRA
(v6.1#6144)