[
https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814731#comment-13814731
]
Tommaso Teofili edited comment on SLING-3223 at 11/6/13 9:16 AM:
-----------------------------------------------------------------
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.
was (Author: teofili):
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)
