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
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
