commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [compress][POLL] High Level API
Date Tue, 01 May 2018 11:03:41 GMT

Is tiny compared the whole lots of

and while the later is not a bad approach it's also a whole lot of belts
and whistles.

I also noticed when re-reading the snippet

    try (Sink<File> sink = ArchiveSinks.forFile(args[1], new
File(args[2]))) { File(args[0]))

that "forFile" is not very descriptive for a high level API.

With jdeb being one of the compress users I am still on the fence whether
(if released some day) I would want to switch to a Sink API or not.
Internally jdeb also uses producer-consumer abstraction - so it could maybe
make sense to try that route.
And with jdeb needing a major overhaul anyway it is a possibility.
But I also have the feeling I might want to have the producer-consumer code
closer to home.
Either way I'd need to find the time to sketch out the plans for jdeb 2.x

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 :)

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.


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