On Wed, May 2, 2018 at 2:13 PM, Stefan Bodewig <bode...@apache.org> wrote:
> On 2018-05-02, Torsten Curdt wrote: > > > So far I didn't think the current API is so horrible. > > I wouldn't call it horrible. > > My ideas about things that should be different and have been epressed in > the compress-2.0 branch I started years ago. To me the most important > things I'd want to change are > > * have self-describing formats like "supports random access", "is > read-only", "is it possible to detect the format by looking into the > first few bytes. > > * have a unified interface for stream like and random access modes > > * separate the archive from the stream. It doesn't feel right to read > from an input stream until it returns -1, then advance some kind o > stream cursor and read from the same stream again. > > * have a more unified view on archive entries (file modes, ownership > information and similar things that tar/cpio/ar and zip provide in > slightly different ways) > > Neither of these points is related to a high level API, though. > > But people ask for a higher level API for "create a ZIP from that > directory" or "extract that archive to the directory over there". Lack > of a "one line API" is something I've seen as criticism on StackOverflow > frequently, but maybe I shouldn't hang out there :-) > I think you can do all that with Commons VFS. Gary > > > Maybe it's rather worth going into a possible unreleased 2.0 branch? > > Tried that, didn't work too well for my past experiments. > > >>> I personally would keep both approaches for now - but somewhere > >>> outside of the official jar. > > As this drags on I think it would be best to just spin the code off to > another branch and get master back into a state we'd feel comforable > with and consider releaseable. > > It's probably better to give the discussion some more time. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
