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 :-) > 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
