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

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

Simon Spero created COMPRESS-414:
------------------------------------

             Summary: 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)