For now, the big picture is to provide a generic although simple
abstraction of the S3-like APIs, with basic features such as handling
user/group, permissions, etc.
As a first step toward something functional, do not dig into any
complex ACL, otherwise it'll probably become an incommensurable mess :-)
Guillaume.
----- Original Message -----
From: "Joacchim" <dav.p...@gmail.com>
To: "SCOP" <scalit...@googlegroups.com>
Sent: Wednesday, February 16, 2011 3:35:37 PM
Subject: [Scality-SCOP] ACL Management for buckets and objects
Hello,
As I work on the cloud migration tool droplet, I thought about copying
the acl with the object.
I went through the library's code in order to find whether I could
retrieve a bucket or a file's acl, and set it in a detailed fashion.
I then understood that retrieving it would be possible (with a wrapper
around dpl_get), but with the current api, I can't seem to set a
detailed acl for an object.
Here comes my question :
Is the goal of the library to provide a generic abstraction of the S3-
like APIs, in which case I should not try to set detailed acls ? Or is
it to provide an as detailed as possible abstraction of those APIs ?
Because if it is a generic abstraction, I thought about writing the
wrapper function I wrote about (and possibly discussing the patch with
the library's development team), but I would not know exactly how to
match the different values of the dpl_canned_acl_t enum with the
possible situations.
So, in the end it comes down to it : should I try to be generic, or
detailed ?
In advance, thanks for the answer
2) For the acl blob, use the "acl" subresource in dpl_get()
----- Original Message -----
From: "Joacchim" <dav.p...@gmail.com>
To: "SCOP" <scalit...@googlegroups.com>
Hello,
--
www.scality.com
Vianney Rancurel
+33 1 7809 8270
+33 6 7737 9967