I went through a few iterations of my own over the weekend and wasn't satisfied with the direction in any of them. This approach looks interesting, though I need to take a closer look.
On 23 April 2018 at 14: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. > > 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 > > -- Matt Sicker <boa...@gmail.com>
