[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [compress] High Level API for Archives

On 2018-04-26, Oliver Heger wrote:

> Recently I had a closer look at streaming libraries like Akka Streams.
> So I had the idea to model the problem in a similar way:

> An archive or deflate operation could be modeled by a flow from a source
> via some filtering or modifying stages to a sink. The source and the
> sink could both either refer to a directory or an archive file. In order
> to create a new archive, the source would point to a directory and the
> sink would represent the archive file to be created. To extract an
> archive file, it would be the other way around. When both the source and
> the sink point to an archive file, you have an update operation. So the
> basic concepts can be combined in a natural way.

> There could be stages that filter for files or archive entries to select
> the content of an archive file to be created or the files to be
> extracted. Maybe it makes also sense to map on entries to manipulate
> them somehow (rename?).

> The API could be extensible by allowing clients to create their own
> implementations of sources, sinks, and flow stages.

> Just some high-level thoughts without having thought that through.

This resonates with some ideas I've had, but I'm afraid this is a bit
too much if the target goal is an examples package :-)

In a way the current "lots of overloaded methods" implementation already
does something similar internally - while keeping files and archive
entries strictly separate in two different classes. Trying to find a
common abstraction for Files read from/written to a directory and
ArchiveEntries really adds another layer of complexity.

I'll see how far I can get by turning the internal work of my current
implementation into APIs. From your high level description sources/sinks
for all the different ways archives can be represented and the filter
operations are already there. The current implementation lacks
projection/transformation, I'll think about that separately.

Finally the sink could be something that just discards the contents and
just lists the files/entries and we could re-implement the Lister class
that way.


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx