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. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
