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

[Thomas J. <ja...@in...>]

I've been thinking a similiar thing for
a while now, as I've been hacking dar quite
a bit for my own purposes and the most annoying
thing really is having to hand down options over
many different layers, otherwise the code
is very easy to work with.

Something along the lines you suggest would
make things much easier for me at least, also
the interface definitions would be more readable.

Contributing code that requires new options would
be made more simple, you would just have to
add an option handler, and then use that option
exactly where you need it.

But why use different classes for the various
parts of dar? As long as your options names are unique,
just use one class, so you don't need to duplicate
options that are needed in more than one part of the code.

Also, are you sure that you can still dynamically link against
a new version of the library, if a class has extra
methods, without recompiling? Don't know much about
C++ and shared libraries myself...

On Fri, May 18, 2007 at 12:24:36PM +0200, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi,
>=20
> 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.).
>=20
> This break ascendant compatibility at each major release, which implies
> some work for each libdar dependent software.
>=20
> I would like you to get your feedback about the following idea to solve
> this problem:
>=20
> 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.
>=20
> 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 opti=
on.
>=20
> 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.
>=20
> Thanks in advance for feedback,
>=20
> Regards,
> Denis.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iD8DBQFGTX7jpC5CI8gYGlIRAp8sAKCizFlPFYnkZVjO65J152jdrERunQCfWauK
> sJQEgxRbL0fPK+OIRhV8Bqc=3D
> =3DRbTW
> -----END PGP SIGNATURE-----
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api