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

Re: [compress][POLL] High Level API

On 2018-05-02, Torsten Curdt wrote:

> So far I didn't think the current API is so horrible.

I wouldn't call it horrible.

My ideas about things that should be different and have been epressed in
the compress-2.0 branch I started years ago. To me the most important
things I'd want to change are

* have self-describing formats like "supports random access", "is
  read-only", "is it possible to detect the format by looking into the
  first few bytes.

* have a unified interface for stream like and random access modes

* separate the archive from the stream. It doesn't feel right to read
  from an input stream until it returns -1, then advance some kind o
  stream cursor and read from the same stream again.

* have a more unified view on archive entries (file modes, ownership
  information and similar things that tar/cpio/ar and zip provide in
  slightly different ways)

Neither of these points is related to a high level API, though.

But people ask for a higher level API for "create a ZIP from that
directory" or "extract that archive to the directory over there". Lack
of a "one line API" is something I've seen as criticism on StackOverflow
frequently, but maybe I shouldn't hang out there :-)

> Maybe it's rather worth going into a possible unreleased 2.0 branch?

Tried that, didn't work too well for my past experiments.

>>> I personally would keep both approaches for now - but somewhere
>>> outside of the official jar.

As this drags on I think it would be best to just spin the code off to
another branch and get master back into a state we'd feel comforable
with and consider releaseable.

It's probably better to give the discussion some more time.


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