Andreas Almroth, 15.10.2009 16:02:
> Why duplicate functionality? Why add support for compression and encryption in backup
> kernel, as well as in the BSMs? We have to make an design decision that either we only
> allow the backup kernel to do it, or only allow the BSMs to do it. My opinion is clear
> from above, leave it to the BSMs, let the storage systems do what they are good at.
This must be a misunderstanding. I just wanted to say: Before
implementing compression and encryption with KMS in every storage module
again and again, we better do it in the kernel.
If all storage modules, where users are interested in such features do
already have them, there is nothing we need to implement. Neither here
But if, for example, we need an encryption for a plain file storage, and
also for a socket tunnel, and we can't just use existing functions, why
implement it twice in the storage modules?
BTW, we have already implemented [g]zip compression in the backup kernel
and SQL syntax for using it. If every storage module would have its own
compression, the different syntax for activating it might become
confusing. OTOH, we could also abandon the kernel compression.
Anyway, if we can agree on specifying compression/encryption/... via the
location string, we can leave away the "Set compression algorithm"
service and defer the decision about where/how to implement these extra
features to later.
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