sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirk Rudolph (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SLING-7364) Transport DistributionPackageInfo as Http headers
Date Mon, 15 Jan 2018 14:39:03 GMT

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

Dirk Rudolph commented on SLING-7364:
-------------------------------------

After looking at the code I got a bit confused what the info actually is. The header send
[contains|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/DistributionPackageUtils.java#L214]
the {{request.type}}, {{request.paths}}, {{remote.package.id}} and {{reference-required}},
which in fact is only a subset of the overall DistributionPackageInfo. Only the {{request.paths}}
makes the length of the header unpredictable long and therefor is blocking for sending the header
as HTTP header. My idea is to let the DistributionContentSerializer write the DistributionPackageInfo
(not the header) and also read it from the InputStream. For vtl this could be as part of the
MANIFEST.MF. But for that I have to make sure that {{request.paths}} can be part of the info
but *not* part of the header. I found the following usages where the header gets read:

- AbstractDistributionPackageBuilder#installPackage() and AbstractDistributionPackageBuilder#readPackage().
In both the info could be read from the known DistributionContentSerializer or SimpleDistributionPackage#fromStream()
- FileDistributionPackageBuilder#readPackageInternal() and ResourceDistributionPackageBuilder#uploadStream(),
same method actually and also in both cases the DistributionContentSerializer is know
- LocalDistributionPackageImporter#importStream(), reads {{remote.package.id}} and {{reference-required}}

So basically, it looks like that request.paths doesn't necessarily be part of the header and
can be read from the package itself at a later stage. So I would like to propose, 

- to remove sending the DistributionPackageInfo as binary stream header prepended to the serialised
content
- send only the necessary (bound in their size) properties as url encoded string as HTTP header
(Sling-Content-Distribution)
- extend the DistributionContentSerlializer by void readInfo(InputStream, Map<String, Object>
info) to read the info

I see that this is a breaking change and so I would like to as if thats "acceptable", or is
there maybe anything i misunderstood? [~marett] [~teofili]


> 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
(v7.6.3#76005)

Mime
View raw message