OSDir

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

Re: [compress][POLL] High Level API


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