[jira] [Comment Edited] (SLING-7364) Transport DistributionPackageInfo as Http headers

["Dirk Rudolph (JIRA)" <ji...@apache.org>]

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

Dirk Rudolph edited comment on SLING-7364 at 1/11/18 4:40 PM:
--------------------------------------------------------------

I thought about a couple of options here:

1. Sending the DistributionPackageInfo as HTTP headers:
That might be the simplest solution, like sending them as url encoded String in Sling-Content-Distribution-Package-Info header. But unfortunately, even though HTTP doesn't specify any limit on the size of headers, server implementations might limit the size. So to reliable implement that the amount of paths in a single package would need to be limited

2. Delegating serialisation of the package headers to the DistributionSerializer
Similar to the deletion package generation (or the content-type), it is the serializer that has knowledge about the format a target system expects and it should also be the responsibility of the serializer to write the info header as part of the body's content. Not sure if this is at all feasible with the way its implemented atm.

3. Don't send the DistributionPackageInfo at all
If the target system is not Sling, its likely that it doesn't understand the package info at all, so it could be made configurable whether to send it or not.

Thoughts?


was (Author: diru):
I thought about a couple of options here:

1. Sending the DistributionPackageInfo as HTTP headers:
That might be the simplest solution, like sending them as url encoded String in Sling-Content-Distribution-Package-Info header. But unfortunately, even though HTTP doesn't specify any limit on the size of headers, server implementations might limit the size. So to reliable implement that the amount of paths in a single package would need to be limited

2. Delegating serialisation of the package headers to the DistributionSerializer
Similar to the deletion package generation (or the content-type), it is the serializer that has knowledge about the format a target system expects and it should also be responsibility of the serializer to write the info header as part of the body's content. Not sure if this is at all feasible with the way its implemented atm.

3. Don't send the DistributionPackageInfo at all
If the target system is not Sling, its likely that it doesn't understand the package info at all, so it could be made configurable whether to send it or not.

Thoughts?

> Transport DistributionPackageInfo as Http headers
> -------------------------------------------------
>
>                 Key: SLING-7364
>                 URL: https://issues.apache.org/jira/browse/SLING-7364
>             Project: Sling
>          Issue Type: Improvement
>          Components: Content Distribution
>    Affects Versions: Content Distribution Core 0.2.10
>            Reporter: Dirk Rudolph
>            Priority: Minor
>
> Currently DistributionPackages are sent over wire including there info as headers in the binary stream. In SLING-7357 I proposed that its the responsibility of the serializer to specify which kind of content it is serializing. Unfortunately as SimpleHttpDistributionTransport prepends the DistributionPackageInfo the content is not of the content type serialized anymore and the consumer side has to first read the package info before the actual content can be read.
> For example in my demo to integrate SCD with solr I had to write a custom UpdateRequestHandler to be able to parse the json I'm sending to solr with SCD:
> https://github.com/Buuhuu/sling-content-distribution-solr/blob/master/sling-content-distribution-solr-loader/src/main/java/com/github/buuhuu/solr/handler/SCDUpdateRequestHandler.java
> If possible it would be nice to have those info transmitted using http headers, which would allow to integrate into other systems as they are.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)