[jira] [Commented] (COMPRESS-414) Provide API for Channel(-ish) Seekable, Possibly Read/Write, Possibly Transactional Compressors & Archivers,

["Simon Spero (JIRA)" <ji...@apache.org>]

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

Simon Spero commented on COMPRESS-414:
--------------------------------------

I think that this could use a fair chunk of the prototyping in the version 2 branch.  
It ought to be possible to evolve an API along the lines discussed above and in the 2 branch, with the existing api becoming deprecated for removal (less removal than becoming the implementation classes becoming not exported to  OSGI and Jigsaw users)

Much of the implementation code could slide into new, private packages already;  the current API could mostly be delegates, and the most of the  test suite that use the public API could become kind of integration tests  (with the other tests following the implementation.) 

Things would work cleaner with a multiproject build, with projects for the general apis, with a separate project for each  archiver / compressor. 

Implementations of formats would be exposed as services  (OSGI declarative and module-info / META-INF/services)

There should also be a  combined single dependency thing (a shadowed / shaded jar, and a Karaf feature.xml?) 

The artifacts for each format could be released on separate schedules (e.g. a bug-fix or performance tweak for 7z  could be released without requiring new releases of everything else (so people just wanting tar don't have to be affected).   

> Provide API for Channel(-ish) Seekable, Possibly Read/Write, Possibly Transactional  Compressors & Archivers, 
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-414
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-414
>             Project: Commons Compress
>          Issue Type: Improvement
>            Reporter: Simon Spero
>
> It would be very useful to have APIs  to support random-access, possibly read-write archives & compressors. 
> These interfaces should probably be based around Seekable, Scatter, and Gather ByteChannels.  
> It might  be necessary or desirable to have these classes extend FileChannel, since there are some important methods that first make their appearance as abstract methods on that class. 
> The methods of interest are the absolute positioned read and write methods, plus force/sync.
>   The use case I'm thinking of for the the non-relative read/write would be for a random-access compressed "file", where it may be useful to keep a cache of decompressed blocks, and where a task may require access to several parts of the file simultaneously.   Nesting this deeper, there might be (well, there are)  a tar.xz file containing a sequence of versions of a maven artifact jar,  and with  an analysis process that  needs  access to two or more of the files simultaneously. 
> A use case requiring  read/write + transactional + sync support would be to support in-place  appending new items to a tar.xz file.  It can be quite useful to be able to perform such updates "in-place"; for safety this requires a log the parts of the existing file that are going to be changed, so that the contents can be recovered in the event of failure.  
> If there is related metadata in a separate transactional resource, it is good to have both stores remain in sync.  The complicated parts are the job of a transaction manager (e.g.  Aries); basic XAResource support is relatively simple.    There are other bits of glue that are useful for handling simple transactions with no transaction manager around, but those can be optional imports.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)