Hello,
just wanted to point out, that TrueVFS/TrueZIP has a NIO.2
SeekableByteChannel implementation. Thats the same thing as would be
needed vor [compress]: https://truezip.java.net/
Bernd
-
To unsubscribe, e-mail: dev-un
Document what you can hold, so that there isn't overly much promise.
On Sun, Sep 29, 2013 at 8:09 AM, Stefan Bodewig wrote:
> Hi all,
>
> over this weekend I added 7z support to the compress antlib which I also
> like to use as a second testbed for Commons Compress - I even found a
> bug for a
> Since we now have multiple archivers that require seeking, I suggest
> we add a SeekableStream class or something along those lines. The
> Commons Imaging project also has the same problem to solve for images,
> and it uses ByteSources, which can be arrays, files, or an InputStream
> wrapper that
On 2013-10-01, Damjan Jovanovic wrote:
> On Tue, Oct 1, 2013 at 6:09 AM, Stefan Bodewig wrote:
>> Reading may be simpler, here you can store the meta-information from the
>> start of the file in memory and then read entries as you go, ZipFile
>> inside the zip package does something like this.
On Tue, Oct 1, 2013 at 6:09 AM, Stefan Bodewig wrote:
> On 2013-09-30, Benedikt Ritter wrote:
>
>> 2013/9/30 Stefan Bodewig
>
>>> I'm in no way as familiar with the format as Damian is but IMHO it is
>>> feasible - but likely pretty memory hungry. Even more so for the
>>> writing side. Similar
On 2013-09-30, Benedikt Ritter wrote:
> 2013/9/30 Stefan Bodewig
>> I'm in no way as familiar with the format as Damian is but IMHO it is
>> feasible - but likely pretty memory hungry. Even more so for the
>> writing side. Similar to zip some information is stored in a central
>> place but in
Hello,
I think it is not related to java, but a general problem of some file
formats in regards to streaming access.
If a format needs seeking/random-access there are basically three options
(with the Java classes but also other languages). The first is having a
random access file (which
2013/9/30 Stefan Bodewig
> On 2013-09-29, Torsten Curdt wrote:
>
> > Hm - it is indeed a little misleading. So I am +0 for an inclusion.
>
> This is what I feel as well.
>
> > Is a stream based implementation of 7z somewhat feasible - at least in
> > theory?
>
> I'm in no way as familiar with the
On 2013-09-29, Torsten Curdt wrote:
> Hm - it is indeed a little misleading. So I am +0 for an inclusion.
This is what I feel as well.
> Is a stream based implementation of 7z somewhat feasible - at least in
> theory?
I'm in no way as familiar with the format as Damian is but IMHO it is
feasibl
Hm - it is indeed a little misleading. So I am +0 for an inclusion.
Is a stream based implementation of 7z somewhat feasible - at least in
theory?
cheers,
Torsten
On Sun, Sep 29, 2013 at 8:09 AM, Stefan Bodewig wrote:
> Hi all,
>
> over this weekend I added 7z support to the compress antlib wh
Hi all,
over this weekend I added 7z support to the compress antlib which I also
like to use as a second testbed for Commons Compress - I even found a
bug for archives that only contain empty directories.
The antlib is based on the interface provided by Archive*Stream even
when it is not using an
11 matches
Mail list logo
