That's more or less the picture :) Take a look at the Core Concepts [1] page, to clarify the doubts you may have about apis, provioders, etc.
Regarding the development process, the steps are usually: 1. Create the metadata classes that describe the api. 2. Create the api classes that will actually perform the requests to the cloud provider. 3. Create the unit and live tests that prove that the api methods work as expected. 4. Create the provider metadata (if any) that describes a provider offering the api. 5. If the provider has additions to the api, create the provider specific api classes and the corresponding tests. At point 3, the api is already usable. Having a concrete provider just adds the location, and some defaults for that concrete cloud provider. I'm starting to write a developer guide detailing each of these points so it is easier to get started. Stay tuned to the wiki! Ignasi [1] http://wiki.apache.org/jclouds/Core%20Concepts On 13 March 2014 23:58, Roman C. Coedo <[email protected]> wrote: > 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!
