I'm all for providing a high-level API. That's fine. I would like a high-level statement first though concerning choices we have or have not considered.
- The high level API is Commons VFS. Why? Why not? - The high level API is Java IO File System. Why? Why not? Gary On Wed, May 2, 2018 at 7:51 AM, Stefan Bodewig <bode...@apache.org> wrote: > On 2018-05-01, Torsten Curdt wrote: > > > https://github.com/apache/commons-compress/blob/master/ > > src/main/java/org/apache/commons/compress/archivers/Archiver.java > > > Is tiny compared the whole lots of > > > https://github.com/apache/commons-compress/tree/master/ > > src/main/java/org/apache/commons/compress/archivers/examples > > > and while the later is not a bad approach it's also a whole lot of belts > > and whistles. > > True. > > > Bottom line: > > > Given that you are currently the main person working on Compress I'd say > - > > whatever you are OK with. > > But you don't really sound super confident/happy about the API - > > otherwise you might not have written this email :) > > TBH I've written this email because my compass for which direction > Compress want to go seems to be severly off. When I started the initial > discussion about how a high level API might look I didn't expect that > those who responded would say "we don't want to maintain a high level > API at all". > > Don't get me wrong, I'm not compaining, not at all, just completely > unsure what the community actually wants. And the last thing I want to > do is to impose my ideas onto a group of people who don't want them but > let me have my way because I happen to be the one doing some work right > now. > > If this only was about example code then I'd be perfectly happy with the > smaller initial idea and probably would even strip out the filtering > parts in order to reduce the number of overloads by half. If we wanted > to provide a useful high level API I'd prefer the second version. > > > I personally would keep both approaches for now - but somewhere > > outside of the official jar. And just give everyone some time to play > > with it. > > Which is another twist I didn't expect. Don't ship the example/high > level stuff with the main artifact at all. Which is also fine with me, > as long as it gets compiled and tested whenever we change "the real > library". > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
