frozen API

Denis Corbin <[email protected]> Thu, 07 Oct 2010 21:03:52 +0200
Newsgroups gmane.comp.sysutils.backup.dar.libdar
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,

Just to let you know that current development code has been frozen for
its API specification. Still remains some documentation to review before
starting the pre-release phase, but all API related documentation are
updated (I still have to review them to fix probable bad spelling and
bad English phrases...)

Some words about the new API.

First, yes, it is a new API. But the old API (4.4.x version) is still
available through a compatibility wrapper included in libdar. So if you
do not want to take advantage of libdar's new features in your program
but want to be able to compile and link against the new API with a
minimum effort, you will have to include "libdar_4_4.hpp" in place of
"libdar.hpp" and use the namespace "libdar_4_4" in place of "libdar".
That's all. Compilation and linking stay the same.

Why yet a new API?

Mainly because for each new feature a new argument to a method somewhere
had to be added, which broke backward compatibility (see API version
4.4.x compared to major release version 2.4.x).

What are the changes between 4.4.x and 5.0.0 API?

Well, first, there is no more any method with a ton of arguments. This
should let code more readable and avoid argument mix. So now, how this
info get passed to libdar? Thanks to a new set of "option" classes.

Each of these "option" classes has a constructor with no argument, which
set the different options to their default values. Beside the
constructor, for each former argument (aka for each feature) can be
found two methods the first is "get_...()" the second is "set_...()".
API user will mainly use the set_...() methods while libdar will read
them thanks to the get_...() ones.

Then what's the advantage of theses classes?

Each new feature will bring a new couple of method for the concerned
option class, which will be set to its default value by the constructor.
This way, adding new feature should no more break backward compatibility
and neither oblige any user program to add argument somewhere even if
the corresponding feature is not used by it.

Where get more detailed information?

Checkout the CVS trunk, and point your browser toward the doc/index.html
page. In addition, if you have Doxygen, you can build the API
documentation or else read the same information directly from libdar
header files (src/libdar/archive_options.hpp; src/libdar/archive.hpp)
Last, you can read src/dar_suite/dar.cpp as a full illustration on how
to use libdar's new API.

Any question/suggestions/remarks about the API and its documentation are
of course welcome in this mailing-list.

Kind Regards,
Denis.

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

iD8DBQFMrhmXpC5CI8gYGlIRAhagAKCuBP514uI2YTx7RjDqz6t+YXtOMgCeKoXu
bwlCzwXI7onWJfC4UGLevN0=
=BS8/
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb