[ 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 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). > 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 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)