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. If not, maybe put the code in an experimental package. > Maybe we need to look at the various users of the API and take that as > the basis for the next step. > > My 2 cents. > Torsten > > On Mon, Apr 23, 2018 at 8:57 PM, Stefan Bodewig <bode...@apache.org> wrote: >> Hi all >> >> I've started to work on COMPRESS-118 and added Archiver and Expander >> classes - without any tests for now. As I'm trying to cover a bunch of >> possible use cases there are lots of inputs or outputs that can >> represent archives. When expanding archives you may want to use >> auto-detect the format or specify it explicitly. You may want to filter >> the files to add/entries to expand. All this leads to an explosion of >> overloads that I'm not comfortable with. >> >> One idea that I came up with is using a fluent interface like >> >> Expander.forFile(someFile).filtering(someFilter).expandTo(someDirectory); >> >> or similar. But before I delve deeper into it, I'd like to collect >> feedback. >> >> And then I'd like to collect additional features that might be >> needed. What I can easily imaging is >> >> * When expanding, don't overwrite existing files when expanding an >> archive (or only if the archive entries are newer. >> >> * Add an API for updating archives - of course this boils down to >> writing a completely new archive with entries taken from two sources. >> >> * we may want to provide a utility class that makes dealing with the >> subclasses of ArchiveEntry easier. Many of them provide a userid, but >> there is no common interface. I'm thinking about something like >> >> https://github.com/apache/ant-antlibs-compress/blob/master/src/main/org/apache/ant/compress/util/EntryHelper.java >> >> Any feedback is very much appreciated. >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
