Am 26.04.2018 um 17:37 schrieb Matt Sicker: > If it helps in design, the most promising approach I found was to integrate > with the java.nio.file API. However, that turns into a sort of hybrid > library between VFS and Compress. However, they are rather strongly related > (if the two libraries were modular, then it wouldn't be such a problem to > combine them). > > On 26 April 2018 at 10:04, Stefan Bodewig <bode...@apache.org> wrote: > >> On 2018-04-24, sebb wrote: >> >>> On 23 April 2018 at 20:48, Torsten Curdt <tcu...@vafer.org> wrote: >>>> TBH I am not such super big fan of adding and maintaining a high level >>>> API at this stage. >>>> You will never find the right abstraction that everyone is happy with. >>>> If you would - well, then that should be the real API afterall. >> >>>> Honestly - I would just add example code for now. Maybe that can turn >>>> into a helper class in the long run. >>>> But for now we would not introduce something we may no longer break. >> >>> I like the idea of introducing it as example code. >>> That makes it obvious that it will change. >> >> As the only people who spoke up prefer to not provide the API as an >> officially supported one, I'm fine with moving the stuff to an examples >> package, add a warning and add unit tests so we now it keeps on working. >> >> Unless anybody yells and says "no we really need this high level API", >> that is. >> >> I'd still like to spend some time and gather feedback on a nicer API >> than many overloads - is fluent the way to go?
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. Oliver >> >>> If not, maybe put the code in an experimental package. >> >> The changeset package is in this state and has been like this for years >> now, I doubt we'd ever get anything out of the experimental phase :-) >> >> Stefan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
