[Dar-libdar_api] Re: API / thread safe libdar

[Denis C. <dar...@fr...>]

Christian Neumann wrote:
> Hi.

Hello,

> I am currently developing a GUI backup program and I am planning to use
> libdar as the backend. But I have some problems with the current API.
> For example, it's hard to use a non-static class member function as an
> callback. The problem has been discussed some months ago in this list
> (thread "callback function context value"). I think that it would be
> _really_ nice to have some sort of thread safe Backup class as Denis
> Corbin proposed. Will this be implemented or are you, Denis Corbin,
> already working on such an API?

The current development version is now thread safe (I hope so ;-) ). 
This has been a lot of work and code rewriting. Next change is adding a 
(void*) pointer as argument to call back functions (as described in the 
"callback function context value").

In the current state, the API specifications are not yet stable, I mean 
there is still some features I want to add for release 2.2.0 (like 
encryption for example), that may impact the libdar API function 
definitions. But, what the target is the following:

I could keep the use of the op_create and other API functions as normal 
function (not class members). They received several new arguments, among 
which, the most important is the "dialog" class (as first argument). 
This object contains all the callback functions, as defined by the 
libdar user. Given this object libdar is able to use the appropriate 
callback function.

the void* argument in each callback function, will let you use 
non-static methods as callback function through the use of a wrapper 
function like this simplified example:

void my_callback_function(std::string & x, void *ptr)
{
      my_class *clptr = dynamic_cast<my_class *>(ptr);
      clptr->my_non_static_method(x);
}



> And another proposal: I would like to get an error/question id
> instead of a complete message. For example:
> 
> --snip--
> enum eMessageID {
> DISC_FULL, PERMISSION_DENIED [...] }

Several aspects have to be seen for that:
- first thing it may make the libdar code less readable. The short name 
of a macro (#define) is not as explicit as the message itself.
- second thing it make thing more complex. As last ressort, you want to 
display the error message to the user.
- third point, the error string is build all along the exception path. 
For example, while you do a backup, while considering a given file, when 
dar opens the file, a system error occurs, thus an exception is created 
with just the sytstem errno string message. The exception is caught at 
the file backup level and the exception is completed with "error while 
saving file xxx :"+[original error message]", and it is thrown again. 
Then at the overall backup level the exception is caught the message is 
transmitted to the user throught a callback function, and the next file 
is processed.
- there is a lot of possible messages (due to the system itself), due to 
the fact that error message are built the way described above.


> 
> class Warning {
>   public: 
>     eMessageID mID;
>     std::slist<std::string> mArgs;
> }
> 
> --
> libdar:
> 
> Warning w;
> w.mID = PERMISSION_DENIED;
> w.mArgs.push_back("/file/that/dar/couldnt/access");
> w.mArgs.push_back("/another/file/that/dar/couldnt/access");
> call_warning_callback(w);
> --
> frontend:
> 
> void warning_callback(Warning& w)
> {
>   switch(w.mID) {
>     case(PERMISSION_DENIED) :
>       [report to user in his own language, tell him what he can do...]
> [...]
> --snip--

The native language support is also a feature for next major release 
(version 2.2.0) ;-)

> 
> That would be very convenient!

yes, I understand.

> 
> Regards,
> Christian
> 

Regards,
Denis.