OSDir

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

Re: [compress] High Level API for Archives


On 23 April 2018 at 20:48, Torsten Curdt <tcurdt@xxxxxxxxx> wrote:
> TBH I am not such super big fan of adding and maintaining a high level
> API at this stage.
> You will never find the right abstraction that everyone is happy with.
> If you would - well, then that should be the real API afterall.
>
> Honestly - I would just add example code for now. Maybe that can turn
> into a helper class in the long run.
> But for now we would not introduce something we may no longer break.

I like the idea of introducing it as example code.
That makes it obvious that it will change.

If not, maybe put the code in an experimental package.

> Maybe we need to look at the various users of the API and take that as
> the basis for the next step.
>
> My 2 cents.
> Torsten
>
> On Mon, Apr 23, 2018 at 8:57 PM, Stefan Bodewig <bodewig@xxxxxxxxxx> wrote:
>> Hi all
>>
>> I've started to work on COMPRESS-118 and added Archiver and Expander
>> classes - without any tests for now. As I'm trying to cover a bunch of
>> possible use cases there are lots of inputs or outputs that can
>> represent archives. When expanding archives you may want to use
>> auto-detect the format or specify it explicitly. You may want to filter
>> the files to add/entries to expand. All this leads to an explosion of
>> overloads that I'm not comfortable with.
>>
>> One idea that I came up with is using a fluent interface like
>>
>> Expander.forFile(someFile).filtering(someFilter).expandTo(someDirectory);
>>
>> or similar. But before I delve deeper into it, I'd like to collect
>> feedback.
>>
>> And then I'd like to collect additional features that might be
>> needed. What I can easily imaging is
>>
>> * When expanding, don't overwrite existing files when expanding an
>>   archive (or only if the archive entries are newer.
>>
>> * Add an API for updating archives - of course this boils down to
>>   writing a completely new archive with entries taken from two sources.
>>
>> * we may want to provide a utility class that makes dealing with the
>>   subclasses of ArchiveEntry easier. Many of them provide a userid, but
>>   there is no common interface. I'm thinking about something like
>>   https://github.com/apache/ant-antlibs-compress/blob/master/src/main/org/apache/ant/compress/util/EntryHelper.java
>>
>> Any feedback is very much appreciated.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx