On 10/28/21 12:42 PM, Casey Bodley wrote:
<snip>
right. for RGWGetObj, all the data eventually streams through
RGWGetObj_CB to be written out to the client via the frontend. the
decompression and decryption filters are wrapping that. so if we
wanted to allow zipper stores the ability to transform the
unencrypted/uncompressed stream, we'd want to give them a chance to
wrap the stream before those other filters are added
in rgw::sal, this could look something like:
virtual RGWGetDataCB* add_filter(RGWGetDataCB* cb) { return cb; }
which by default doesn't add any filters, but a store could override
this to return some other filter that wraps 'cb'
It occurs to me that we probably want encryption and compression to be
per-store anyway, since different stores may have different built-in
capabilities for those features. For example, a PostgreSQL database
with it's own encryption enabled. This means we probably want to move
the encryption/compression into the zipper stack, rather than above it,
regardless.
Daniel
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
