In section 2.3, development process, I suggest reordering the vault
operations based on assumed complexity:
1. Authentication and Vault
2. Archive list and delete
3. Archive upload
4. Archive multi-part upload (optional)
5. Provider implementation
You can use the AWS console to bootstrap a few sample archives for list
and delete.
I think we should further break down step 1 into:
0. Provider skeleton
1. Vault operations
Step 0 might require some more time to for general ramp up, creating the
skeleton in jclouds-labs-aws, and creating API metadata. We should pad
this time out a little bit so your do not start the summer behind
schedule.
Discussed offline, but having a BlobStore view would make a good step 6.
While the Glacier model does not lend itself well to random read
operations, we should allow applications written against Glacier
expectations to move to other traditional blobstore providers, e.g.,
Swift. We may need to add an accommodation in the BlobStore API to hint
that an archive will be read in the future which would help with
multiple archive reads. For Glacier this would initiate a job and for
other providers this would have no operation.
Some nits: decapitalize jclouds, capitalize "I"
Overall this looks like an exciting proposal!
On Mon, Mar 17, 2014 at 02:09:14PM +0100, Roman Coedo wrote:
> Hi,
>
> I've made a draft for my proposal to implement jclouds' support for Amazon
> Glacier and I'd like to share it with you. Any suggestions would be really
> appreciated.
>
> You can check it on this link:
> https://drive.google.com/file/d/0B3lMiDkiDwpUanRrZUphSkNEX2s/edit?usp=sharing
>
> Thanks for your time.
--
Andrew Gaul
http://gaul.org/
