Hi Ingo,
Misunderstandings is a great source for discussions ;-)
>Hi Andreas,
>>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.
Most enterprise backup systems provide very good support for KMS and encryption with extensive management. This is why I ask why we want the backup kernel to implement encryption, when it is already implemented, and same vendors would just have to extend their existing functionality into their new BSM.
Also, please keep in mind that most user won't have multiple BSM installed. Most customers only have one enterprise backup product, leaving with typically two registered BSMs; vendor plugin and the default file plugin.
>If all storage modules, where users are interested in such features do
>already have them, there is nothing we need to implement. Neither here
>nor there.
>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?
True, for the default file backup plugin, we would need to implement our own encryption facility, if we choose to support encryption. Backup to file is in my opinion just another BSM module, and thus removed from the backup kernel.
>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.
All I say is that gzip compression is not always the best for the end storage, thus leave it to the storage to decide.
However, I do believe the user should be able to request compression/encryption through variable settings or SQL commands. The actual backup would then fail if the requirements cannot be fulfilled. Using SQL commands we have a unified method for the user to specify, regardless if the BSM module can fulfil or not.
>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.
Allowing both ways (well we can't really stop the URL way) will give maximum flexibility for users and BSM implementers.
Best regards / Cordialement
Andreas Almroth
