You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Dirk Rudolph (JIRA)" <ji...@apache.org> on 2018/01/09 09:41:00 UTC
[jira] [Updated] (JCRVLT-259) Support pluggable compression formats
[ 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)