[Dar-libdar_api] more stability on libdar API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Thanks in advance for feedback,

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGTX7jpC5CI8gYGlIRAp8sAKCizFlPFYnkZVjO65J152jdrERunQCfWauK
sJQEgxRbL0fPK+OIRhV8Bqc=
=RbTW
-----END PGP SIGNATURE-----