Re: [Dar-libdar_api] more stability on libdar API

[Johnathan B. <jk...@ro...>]

Hi Denis,

On Friday 18 May 2007 6:24 am, Denis Corbin wrote:
> Hi,
>
> For almost each added feature, I have to add new parameter(s) to the
> archive class's constructors or methods. This is annoying for all
> software that rely on libdar (dar command line programs, kdar, etc.).
>
> This break ascendant compatibility at each major release, which implies
> some work for each libdar dependent software.
>
> I would like you to get your feedback about the following idea to solve
> this problem:
>
> The idea is very simple, replace the plethora of *optional* arguments
> found in constructor and archive::op_* methods by a single one which type
> is a class, class which name would be isolate_option, create_option,
> extract_option, and so on.
>
> All theses class would have a default constructor (with no argument),
> along with a list of methods to set the different options (slicing,
> encryption, compression, etc.). then, as new feature get added, a new
> method of in theses option classes would be added. Not using this new
> method would only let libdar behaves with default value for this new
> option.
>
> Old software would continue to work with new libdar API and less work
> would have to be done for libdar dependent software. Using a new feature
> by libdar dependent programs could be done asynchronously from libdar's
> release, this brings more freedom for anyone around libdar's API.

This is a great idea! I'm looking forward to it.

>
> Thanks in advance for feedback,
>
> Regards,
> Denis.

Cheers,
JB