Hi!

I'm working on a draft for a proposal to implement Glacier support (
https://issues.apache.org/jira/browse/JCLOUDS-457) as a GSoC project, and
i'm trying to understand the core concepts of jclouds in order to find the
right approach to attack it.

I think i understand the 3 different levels of abstraction jclouds is based
on: Views, APIs and Providers. I get this concept with, let's say S3.
Amazon offers it's API to access their cloud storage service and Google
does as well. The Provider in this case would describe the most specific
functionality of a vendor cloud, and the API would be an abstraction
gathering their common behavior. But in the case of Amazon Glacier it is
blurrier, there is no other vendor offering their API (i think), therefore
i wouldn't be able to take any common behavior and the abstraction would
make no sense. Am i missing something? Maybe the Provider describes a
concrete endpoint (us-east, us-west, eu...) instead of a vendor, and all
those endpoints share the same API?

Regarding the developing process and the project break down, i thought
about an incremental build method, where i start developing and testing the
provider's most basic functionality of the lowest level of abstraction (the
provider) and i keep implementing extra operations until it's done. Once
the provider is done, i would be able to move to the API, and finally to
the Blobstore. Do you think this is a good approach?

I also dedicated a couple of days to learn more about both S3 and Glacier,
so now i feel like i can dive into jcloud's source code without being
completely lost. My next step will be studying the blobstore view and a
similar provider/api to the one i will implement. Is there any other
Glacier-like cloud service already implemented or should i stick with s3
and aws-s3?

Thanks for your time!

Reply via email to