One more clarification.
It is not my intention to prevent an implementation to return different
error codes and require it to use only 0 and 1.
On the contrary, my specification puts no restrictions on what error codes
are used. The only requirement is that errors should be distinguishable from
non-errors. This is because I believe that there is no need for adding any
additional requirements at the moment.
Again, if you see a need to distinguish different error situations for any
of the services we are currently considering, please let me know.
Rafal
Ingo Strüwing wrote:
> Hi Rafal, Andreas,
>
> Rafal Somla, 27.10.2009 09:35:
>
> ...
>> Andreas Almroth wrote:
> ...
>>> Error codes must be standardized in the BSM API as else there would be
>>> no way for the backup kernel to decide whether to abort, continue or
>>> act on error.
>> My idea is that if BSM reports error, then it is a fatal error and BSM
>> can not be used after that. Any "non-fatal error", after which BSM can
>> continue to serve the user, is not reported as an error but is signalled
>> as a valid reply from a service.
>>
>> For example, if service S10 is called to get information about backup
>> image but the location does not contain any data, this is signalled in a
>> reply from the service which completes successfully. This is so because
>> after such situation the storage session is still usable and the user
>> can e.g., create a new image at this location.
>>
>> In such design, the only sensible thing which backup kernel can do when
>> BSM signals error is to report it and abort. If other action is
>> possible, this would depend on the context in which BSM was called. Thus
>> I don't see it necessary that errors reported by BSMs must be
>> interpreted by its user.
>
>
> As mentioned in an earlier message, I am more with Andreas. Your design
> proposal requires to foresee all non-fatal errors. If a new one arises
> later, we need to change the interface.
>
> ...
>
>
> Regards
> Ingo
