[ https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814731#comment-13814731 ]
Tommaso Teofili commented on SLING-3223: ---------------------------------------- thanks for your comments Tobias. bq, way to little documentation (javadoc, general architecture) yes, while I have some doc written in a README.md, javadoc needs to be improved. bq. 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 good points, then trying to get rid of the headers at all sounds like the best option bq 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?) it's not something missing, I'd like to provide an HTTP/REST API for working with agents, that including triggering replication, checking/updating configuration, checking queues (TBD), creating/deleting agent (TBD). If there's a smarter way of doing such things you may think of just let me know. Current HTTP API has: HTTP POST (/w parameters) to _http://host:port/system/replication/agents_ for triggering replication of all existing agents HTTP POST (/w parameters) to _http://host:port/system/replication/agent/foo_ for triggering replication of agent foo HTTP GET _http://host:port/system/replication/agent/configuration/foo_ for retrieving configuration of agent foo HTTP POST (/w parameters) to _http://host:port/system/replication/agent/configuration/foo_ for updating configuration of agent foo bq. I would reconsider if Activate and Deactivate really are good names. sure, I agree "add" and "delete" sound more appropriate. bq. btw: how is deactivate implemented? not via an empty content package? an empty package (see _VoidReplicationPackage_) bq. 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 right, that's hard to do in general if e.g. create operations are not "atomic" (create /a/b, persist, create /a/b/c persist, create /a/b/c/d etc.) so depending on the use case something like collecting "bunch" of changes may work better; however that's good you raised the point as that will need to be handled properly. bq. 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? it's the former, but it's not just for HTTP, they're used for authenticate _TransportHandlers_ which may deliver content to either an HTTP endpoint (most often) or not (e.g. file system, or other) bq. 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 ? I agree that can be much improved, that's just used from the receiving servlet for reading a replication package stream to install the package on the receiving instance. bq. suggest to add package-info.java files with the bundle export information over <Export-Package> elements in the pom.xml agreed while collecting other feedback (if any) I'll work on the topics brought by Tobias. > 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)