[
https://issues.apache.org/jira/browse/JCRVLT-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-259:
--------------------------------
Description:
The new feature to suppress compression for already compressed binaries
introduced in JCRVLT-163, has been implemented with Apache Sling Content
Distribution in mind to get best performance while still keep bytes on the wire
as small as affordable [0].
Wouldn't it make sense for such cases to support different compression formats
as well, especially thinking about snappy or lz4?
Currently there is a pair for compressing and decompressing implementations,
JarExporter and ZipArchive/ZipStreamArchive. Those are used by the
PackageManagerImpl for example to open or assemble a new package. Adding
support for further compression formats could be done for example by
implementing a registry holding the constructors for compression and
decompression implementations, where the one of choice could be requested by
the ExportOptions (defaulting to jar/zip as it is now).
[0]
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L190
was:
The new feature to suppress compression for already compressed binaries
introduced in JCRVLT-163, has been implemented with Apache Sling Content
Distribution in mind to get best performance while still keep bytes on the wire
as small as affordable [0].
Wouldn't it make sense for such cases to support different formats as well,
especially thinking about snappy or lz4?
Currently there is a pair for compressing and decompressing implementations,
JarExporter and ZipArchive/ZipStreamArchive. Those are used by the
PackageManagerImpl for example to open or assemble a new package. Adding
support for further compression formats could be done for example by
implementing a registry holding the constructors for compression and
decompression implementations, where the one of choice could be requested by
the ExportOptions (defaulting to jar/zip as it is now).
[0]
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L190
> Support pluggable compression formats
> -------------------------------------
>
> Key: JCRVLT-259
> URL: https://issues.apache.org/jira/browse/JCRVLT-259
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
> Reporter: Dirk Rudolph
>
> The new feature to suppress compression for already compressed binaries
> introduced in JCRVLT-163, has been implemented with Apache Sling Content
> Distribution in mind to get best performance while still keep bytes on the
> wire as small as affordable [0].
> Wouldn't it make sense for such cases to support different compression
> formats as well, especially thinking about snappy or lz4?
> Currently there is a pair for compressing and decompressing implementations,
> JarExporter and ZipArchive/ZipStreamArchive. Those are used by the
> PackageManagerImpl for example to open or assemble a new package. Adding
> support for further compression formats could be done for example by
> implementing a registry holding the constructors for compression and
> decompression implementations, where the one of choice could be requested by
> the ExportOptions (defaulting to jar/zip as it is now).
> [0]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L190
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
