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