Re: more stability on libdar API

--===============0382696304==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline


--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quite a lot of new lines of code there ;-)

But I see that you "only" modified the external interfacing
layer of the libdar/* stuff, which is probably enough
to limit upgrading hassles for code that links against libdar,
but people that want to hack the code (i.e. me ;-) still have
a lot of option passing to do when they want to do
things in the depth of dar... So: any plans to propagate
those changes further?

To illustrate, in order to add a new option that basically extends
dar by "remote-control-by-pipe-over-stdin/stderr"-mechanism, I had
to change 24 hpp/cpp files (+4 new ones), with maybe 6 where anything "func=
tional"
happens and 11 of where I just added a new
parameter to member functions that hand this parameter down
to another layer (I can mail you a patch agains 2.3.3 if you are interested
in more details).

If you had just one option class instance, that you could hand
down all over the place (for instance making it a parameter
in any class constructor of notice), one would
just have to change the option parsing in dar_suite/* and
the precise code that does something "real" in libdar/* to add new
features.

Of course, this might all a bit much to ask to implement, since
that would mean changing even larger parts of the libdar code... hmm... just
a random thought really...-

     Regards,
           Thomas


On Thu, May 24, 2007 at 09:48:48PM +0200, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello,
>=20
> CVS is up to date with new API. Tutorial has also been updated.
>=20
> Regards,
> Denis.
>=20
>=20
> Denis Corbin wrote:
> > Hello Johnathan, Hello Thomas,
> >=20
> > Thanks for your feedback. I have thus started moving archive's options
> > in several classes. It is not yet in CVS as it is not yet completed, but
> > seen the impact on the command-line tools, as Thomas said, it already
> > greatly improved readability!
> >=20
> > Kind Regards,
> > Denis.
> >=20
> > Denis Corbin wrote:
> >> 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 t=
ype
> >> 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 o=
ption.
> >=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 featu=
re
> >> 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.
> >=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iD8DBQFGVewgpC5CI8gYGlIRAlLCAJ93UxgnSbyDngS4aZAtYgp6ou6rkwCfaJcp
> 8WmzYJNu6c0r9yXp+ubLjpk=3D
> =3D5jP9
> -----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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGVg3EgF9cFv867HwRAh+hAKCWwJ35uccukr/dmCOh0PwcUEOtZwCbBKOJ
WAu9gSmf594WcYjcjBKvLPw=
=Drd/
-----END PGP SIGNATURE-----

--opJtzjQTFsWo+cga--


--===============0382696304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
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/
--===============0382696304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Dar-libdar_api mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

--===============0382696304==--