[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365006#comment-15365006
]
Tommaso Teofili commented on SLING-5815:
----------------------------------------
thanks for the review [~mpetria].
bq. 1. I think the RR should still be part of the signature and not wrapped in
an object
I think it can be part of the signature, not sure what looks best though, I do
not have a strong opinion there
{quote}
2. I am a bit concerned about the path expanding that happens when you want to
pass only simple paths to the serializer. For a request that contains
+/content/a/.* it will have to traverse the entire subtree and potentially
create a very big list of paths which will end up in the filter.xml. Maybe we
can define a export structure that contains the minimized information without
requiring to traverse the tree before passing it to serializer: an ExportFilter
that contains a set of TreeFilter, each TreeFilter contains a root path and two
lists of excluded and included PathFilters. So basically passing down to the
serializer the responsibility of decoding the filters. We can have an utility
method (ExportFilter.getCoveredPaths(ResourceResolver) or
ExporterFilterUtils.getCoveredPaths(ExporterFilter, ResourceResolver)) to
evaluate the paths, and that can be used by Kryo and Avro.
{quote}
the attached patch is a draft, I'm not planning to commit it as it is; I agree
that part is not good enough yet. We have the FileVault use case where filters
are defined as rules and it's FV's responsibility to match them while
traversing the resource tree, while looking into the other serializers I
started to think that it shouldn't be the serializer responsibility to decode
and expand the filters while traversing the hierarchy of resources, the best
would be if it would just be responsible of transforming a list of paths
(eventually with some white / black list on properties) into a binary and
viceversa. On the other hand I agree that the current patch could have problems
with big subtrees as you'd have a possibly huge list of paths originated after
having traversed the whole subtree. I agree on the proposal of having an export
structure which encodes such filters in a way that, together with some utility
methods, doesn't require serializers' implementors to re-implement such
expansion logic.
Also note that {{DistributionExportOptions}} and {{DistributionImportOptions}}
are concrete classes at the moment holding very few information, but I was
thinking that maybe they could be {{@ProviderType}} interfaces, that can be
enriched over time without breaking backward compatibility.
> Expose DistributionContentSerializer
> -------------------------------------
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
> Reporter: Tommaso Teofili
> Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from
> _org.apache.sling.distribution.core_ in order to allow implementation of
> custom serialization formats (e.g. Avro and Kryo defined in
> _org.apache.sling.distribution.extensions_).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
