Very helpful guidelines Ignasi, i think i'm in a good position to finish my proposal now. I look forward to your guide.
Thanks :) 2014-03-14 10:02 GMT+01:00 Ignasi Barrera <[email protected]>: > 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! >
