OSDir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [compress][POLL] High Level API


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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>