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

Re: [compress] High Level API for Archives

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 <bodewig@xxxxxxxxxx> wrote:

> On 2018-04-24, sebb wrote:
> > On 23 April 2018 at 20:48, Torsten Curdt <tcurdt@xxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx

Matt Sicker <boards@xxxxxxxxx>