commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [compress][POLL] High Level API
Date Wed, 02 May 2018 14:01:14 GMT
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 <bodewig@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message