commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@vafer.org>
Subject Re: [compress][POLL] High Level API
Date Wed, 02 May 2018 14:46:57 GMT
>
> > 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 that's actually the main (if not only) reason why I am so hesitant
to give a +1 for adding it as is.

So far I didn't think the current API is so horrible.
But if I (as a user) don't see a benefit in switching
then I am wondering about other peoples use cases.
...and whether it's worth adding to maintain.

Maybe it's rather worth going into a possible unreleased 2.0 branch?
Rethinking the API?


.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".
>

Well, or use an experimental package. Just not a great fan of those.
It's like showing users a big red button telling them not to press it.

On the other hand - how we get good feedback? It's not like it's a big
project with many user on the users list.
Right now I only see the option to check maven central for projects that
use compress and look at their code.

Maybe we get some feedback when they press the red button ;)

cheers,
Torsten

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