Re: more stability on libdar API

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

Thomas Jacob a wrote
> Quite a lot of new lines of code there ;-)

yep, a lot of new lines, a bit painful, but necessary. :-)

> 
> 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?

It will depend on the feasability. For example some internal routing
like archive::op_create_in_sub are used by archive creation, isolation
and merging. Theses three operations do not have exactly the same set of
options, thus the extension to the options classes deeper in libdar's
code may raise some problem, problem that will be addresses on a case by
case basis.

The first an main objective was to let external aplication live their
lives while new features get added. This is now achieved for all that
concern dar's features. For dar_manager, this will be done later if new
feature have to be added.

I guess that when new features will get added, I will extend the class
options more deeply inside libdar (like filter.cpp and archive class sub
routines), because I also find fastidious to modify that many headers
when adding just a single new argument...

> 
> 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 "functional"
> 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).

I guess you rather can let this patch available publicly in the patch
tracker on sourceforge(
https://sourceforge.net/tracker/?group_id=65612&atid=511614 ). It may
also be interesting for other people than just me.

I guess that when new features will get added, I will extend the class
options more deeply inside libdar (like filter.cpp and archive class sub
routines), because I also find fastidious to modify that many headers
when adding just a single new argument...



> 
> 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.

Well, I thought about having a more hierarchically set of classes to
handle options, but I also considered the user point of view. Providing
a single class let the API user easily get the set of options available
for a given operation without having to look for parent classes, or
checking whether an options from a single global class is available for
a particular operation.

This also bring independency between the different operations when
adding new feature.

> 
> 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...-

Last point is that I know dar's implementation is not that perfect (even
if it is far from being the last of my concerns), there is still some
point that can be made better in regard to readability, efficiency,
state of the art, 'beauty' of the ideas. When dar will get stable (i.e.:
when nobody will request new features) I think I will consider this
aspect more globally in this application ;-)
In the meanwhile, I have plenty of interesting features to add! Note
that I try as much as possible to keep the source 'open', by 'open' I
mean that I spend the necessary effort when implementing a new feature
to keep other potential future features still be possible to implement
nicely and efficiency.

> 
>      Regards,
>            Thomas
> 
>

Thanks for feedback!

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

iD8DBQFGVs4HpC5CI8gYGlIRAjzsAKCt6YeHTePlrLG2KyWwDxZyv+y5JQCgjugA
XV2UsZuI1AWyT7LYy+gkSSQ=
=GKsg
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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/