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? > > > 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 > > -- Matt Sicker <boa...@gmail.com>
