if it is visible to the zipper stack, stuff like encryption should
have default implementations?
Matt
On Fri, Oct 29, 2021 at 9:57 AM Daniel Gryniewicz <dang@xxxxxxxxxx> wrote:
>
>
>
> 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
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
