You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Grig Gheorghiu <gr...@gmail.com> on 2010/11/04 22:13:13 UTC
[libcloud] Cloud storage providers/drivers
Hello,
I was wondering if there are any plans for libcloud to support various
cloud-based storage backends, such as Amazon S3, Rackspace CloudFiles,
etc. I think it would be an interesting addition to libcloud. I
wouldn't mind giving S3 a shot for example. Let me know if there is
any interest.
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Dan Di Spaltro <da...@cloudkick.com>.
I think getting the abstraction should be easy. A generic object
store is a pretty simple interface.
-Dan
On Thu, Nov 4, 2010 at 2:13 PM, Grig Gheorghiu <gr...@gmail.com> wrote:
> Hello,
>
> I was wondering if there are any plans for libcloud to support various
> cloud-based storage backends, such as Amazon S3, Rackspace CloudFiles,
> etc. I think it would be an interesting addition to libcloud. I
> wouldn't mind giving S3 a shot for example. Let me know if there is
> any interest.
>
> Grig
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Paul Querna <pa...@querna.org>.
On Thu, Nov 4, 2010 at 6:16 PM, Grig Gheorghiu <gr...@gmail.com> wrote:
> On Thu, Nov 4, 2010 at 2:48 PM, Eric Woods <wo...@gmail.com> wrote:
>> Hi Grig,
>>
>> We did address this in libcloud's Java initiative. After implementing a Java port of libcloud, we pulled SimpleCloud under the libcloud umbrella to provide storage, queue, and table services. Following the libcloud design patterns, we've implemented working adapters for Amazon S3 and Nirvanix. Rackspace has also expressed interest in contributing an adapter for CloudFiles. Take a look at the Java repository for the implementation: https://svn.apache.org/repos/asf/incubator/libcloud/sandbox/java/trunk/src/simplecloud/storage
>>
>> I think this would be great in the python base, too.
>>
>
> Thanks for the pointers to the Java code.
>
> So how would you envision adding storage providers to the python
> codebase? Would there be a simplecloud directory under the top
> libcloud directory, in parallel with the libcloud directory which
> contains base.py? So something like:
>
> libcloud/
> libcloud/
> base.py
> providers.py
> drivers/
> simplecloud/
> storage/
> base.py
> providers.py
> drivers/
>
> ....and then you would define the base storage classes similarly to
> the Java interfaces in simplecloud/storage/base.py, and the actual
> implementations in drivers/S3.py.
>
> Would this make sense?
No, simplecloud in a directory name does not make sense. 'storage' would.
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Wed, Jan 5, 2011 at 4:11 PM, Jerry Chen <je...@apache.org> wrote:
>
> On Jan 5, 2011, at 6:04 PM, Joe Schaefer wrote:
>
>> httpd shipped pcre for ages, which was BSD-licensed.
>> If you go looking through the documentation at
>>
>>
>> http://www.apache.org/legal/resolved.html#category-a
>>
>>
>> you'll see lots of Apache-compatbile licenses that have
>> already been approved for inclusion in our work.
>
> Wonderful. Thank you!
>
That's good news! I'll try to make some progress with the S3 code then.
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Jerry Chen <je...@apache.org>.
On Jan 5, 2011, at 6:04 PM, Joe Schaefer wrote:
> httpd shipped pcre for ages, which was BSD-licensed.
> If you go looking through the documentation at
>
>
> http://www.apache.org/legal/resolved.html#category-a
>
>
> you'll see lots of Apache-compatbile licenses that have
> already been approved for inclusion in our work.
Wonderful. Thank you!
> ----- Original Message ----
>> From: Jerry Chen <je...@apache.org>
>> To: libcloud@incubator.apache.org
>> Sent: Wed, January 5, 2011 6:58:47 PM
>> Subject: Re: [libcloud] Cloud storage providers/drivers
>>
>>
>> On Jan 5, 2011, at 5:53 PM, Joe Schaefer wrote:
>>
>>> BSD is fine. There may be other reasons to not include the code,
>>> but the license isn't one of them.
>>>
>>> Why would you think otherwise?
>>
>> We ran into a hitch earlier in the project regarding licensing, so I can
>> appreciate Grig's caution for license compatibility.
>>
>> Joe, do you have an example of an existing Apache project incorporating BSD
>> code?
>>
>> Thanks,
>> Jerry
>
>
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Joe Schaefer <jo...@yahoo.com>.
httpd shipped pcre for ages, which was BSD-licensed.
If you go looking through the documentation at
http://www.apache.org/legal/resolved.html#category-a
you'll see lots of Apache-compatbile licenses that have
already been approved for inclusion in our work.
----- Original Message ----
> From: Jerry Chen <je...@apache.org>
> To: libcloud@incubator.apache.org
> Sent: Wed, January 5, 2011 6:58:47 PM
> Subject: Re: [libcloud] Cloud storage providers/drivers
>
>
> On Jan 5, 2011, at 5:53 PM, Joe Schaefer wrote:
>
> > BSD is fine. There may be other reasons to not include the code,
> > but the license isn't one of them.
> >
> > Why would you think otherwise?
>
> We ran into a hitch earlier in the project regarding licensing, so I can
>appreciate Grig's caution for license compatibility.
>
> Joe, do you have an example of an existing Apache project incorporating BSD
>code?
>
> Thanks,
> Jerry
Re: [libcloud] Cloud storage providers/drivers
Posted by Jerry Chen <je...@apache.org>.
On Jan 5, 2011, at 5:53 PM, Joe Schaefer wrote:
> BSD is fine. There may be other reasons to not include the code,
> but the license isn't one of them.
>
> Why would you think otherwise?
We ran into a hitch earlier in the project regarding licensing, so I can appreciate Grig's caution for license compatibility.
Joe, do you have an example of an existing Apache project incorporating BSD code?
Thanks,
Jerry
Re: [libcloud] Cloud storage providers/drivers
Posted by Joe Schaefer <jo...@yahoo.com>.
BSD is fine. There may be other reasons to not include the code,
but the license isn't one of them.
Why would you think otherwise?
----- Original Message ----
> From: Grig Gheorghiu <gr...@gmail.com>
> To: libcloud@incubator.apache.org
> Sent: Wed, January 5, 2011 6:51:06 PM
> Subject: Re: [libcloud] Cloud storage providers/drivers
>
> Hello everybody, and Happy New Year.
>
> I asked the question on the AWS forum if the AWS S3 sample code can be
> re-licensed with an Apache license. Here's the reply I got:
>
> "Ultimately this is up to the project into whom you are incorporating
> the code and their legal advice, however it’s very common in the
> industry for Apache licensed projects to incorporate BSD licensed
> works. For example many of the Apache Software Foundation’s projects
> do this."
>
> So I'm still not sure if the BSD-licensed AWS S3 code would be
> acceptable for inclusion in libcloud or not. If anybody on this list
> has any guidance, please let me know.
>
> Grig
>
> On Tue, Nov 16, 2010 at 12:55 PM, Jed Smith <je...@jedsmith.org> wrote:
> > On Mon, Nov 15, 2010 at 12:10 PM, Eric Woods <wo...@gmail.com> wrote:
> >
> >> Unfortunately I can't answer since it's a legal matter. Do you have legal
> >> counsel available to determine the licensing compatibility? Paul, Jerry
>are
> >> you familiar with these licensing issues or how to proceed?
> >>
> >
> > It is my understanding - and I might be wrong - that as part of working
with
> > the ASF (maybe it's an incubator restriction), all files checked in must be
> > licensed under the Apache License.
> >
> > --
> > Jed Smith
> > jed@jedsmith.org
> >
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
Hello everybody, and Happy New Year.
I asked the question on the AWS forum if the AWS S3 sample code can be
re-licensed with an Apache license. Here's the reply I got:
"Ultimately this is up to the project into whom you are incorporating
the code and their legal advice, however it’s very common in the
industry for Apache licensed projects to incorporate BSD licensed
works. For example many of the Apache Software Foundation’s projects
do this."
So I'm still not sure if the BSD-licensed AWS S3 code would be
acceptable for inclusion in libcloud or not. If anybody on this list
has any guidance, please let me know.
Grig
On Tue, Nov 16, 2010 at 12:55 PM, Jed Smith <je...@jedsmith.org> wrote:
> On Mon, Nov 15, 2010 at 12:10 PM, Eric Woods <wo...@gmail.com> wrote:
>
>> Unfortunately I can't answer since it's a legal matter. Do you have legal
>> counsel available to determine the licensing compatibility? Paul, Jerry are
>> you familiar with these licensing issues or how to proceed?
>>
>
> It is my understanding - and I might be wrong - that as part of working with
> the ASF (maybe it's an incubator restriction), all files checked in must be
> licensed under the Apache License.
>
> --
> Jed Smith
> jed@jedsmith.org
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Jed Smith <je...@jedsmith.org>.
On Mon, Nov 15, 2010 at 12:10 PM, Eric Woods <wo...@gmail.com> wrote:
> Unfortunately I can't answer since it's a legal matter. Do you have legal
> counsel available to determine the licensing compatibility? Paul, Jerry are
> you familiar with these licensing issues or how to proceed?
>
It is my understanding - and I might be wrong - that as part of working with
the ASF (maybe it's an incubator restriction), all files checked in must be
licensed under the Apache License.
--
Jed Smith
jed@jedsmith.org
Re: [libcloud] Cloud storage providers/drivers
Posted by Eric Woods <wo...@gmail.com>.
Unfortunately I can't answer since it's a legal matter. Do you have legal counsel available to determine the licensing compatibility? Paul, Jerry are you familiar with these licensing issues or how to proceed?
On Nov 15, 2010, at 10:48 AM, Grig Gheorghiu wrote:
> On Mon, Nov 15, 2010 at 7:31 AM, Eric Woods <wo...@gmail.com> wrote:
>> Hi Grig,
>>
>> I found that the authentication code was the most difficult to port, especially for AWS. Java and Python have very different utilities for handling encoding/encryption schemes, so most of my authentication code was written from scratch. By all means, do what makes the most sense for Python.
>>
>> I expect that the factoring of common components (e.g. connections), libcloud components (e.g. Node), and storage components (e.g. Item) and general design patterns are what can be leveraged most from the Java work. As you dive into this, please feel free to ask questions and provide feedback on the Java structure.
>>
>> Thanks,
>> Eric
>
> OK, will do. But in terms of licensing, is it OK to include code from
> the AWS sample S3 code?
>
> Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Mon, Nov 15, 2010 at 7:31 AM, Eric Woods <wo...@gmail.com> wrote:
> Hi Grig,
>
> I found that the authentication code was the most difficult to port, especially for AWS. Java and Python have very different utilities for handling encoding/encryption schemes, so most of my authentication code was written from scratch. By all means, do what makes the most sense for Python.
>
> I expect that the factoring of common components (e.g. connections), libcloud components (e.g. Node), and storage components (e.g. Item) and general design patterns are what can be leveraged most from the Java work. As you dive into this, please feel free to ask questions and provide feedback on the Java structure.
>
> Thanks,
> Eric
OK, will do. But in terms of licensing, is it OK to include code from
the AWS sample S3 code?
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Eric Woods <wo...@gmail.com>.
Hi Grig,
I found that the authentication code was the most difficult to port, especially for AWS. Java and Python have very different utilities for handling encoding/encryption schemes, so most of my authentication code was written from scratch. By all means, do what makes the most sense for Python.
I expect that the factoring of common components (e.g. connections), libcloud components (e.g. Node), and storage components (e.g. Item) and general design patterns are what can be leveraged most from the Java work. As you dive into this, please feel free to ask questions and provide feedback on the Java structure.
Thanks,
Eric
On Nov 14, 2010, at 5:15 PM, Grig Gheorghiu wrote:
> Quick update: I've been trying to port the Java code from
> simplecloud/storage but I've had mixed success. I am tempted to start
> from scratch and use the Python code from the sample S3 code published
> by Amazon here:
> http://aws.amazon.com/code/134?_encoding=UTF8&jiveRedirect=1 . The
> license is 'new BSD'. Would it be appropriate to base the libcloud S3
> driver on that code and license? I would like to at least use the
> authentication code from that sample.
>
> Grig
>
> On Thu, Nov 4, 2010 at 6:01 PM, Grig Gheorghiu <gr...@gmail.com> wrote:
>> On Thu, Nov 4, 2010 at 5:57 PM, Tom Davis <to...@dislocatedday.com> wrote:
>>> I like this structure, too. +1
>>
>> One thing with the refactoring of the directory structure is that
>> tools that expect to import libcloud modules in a certain way might
>> break. Not sure if that is a big concern or not.
>>
>>> I am also intrigued by Grig's DASH idea!
>>
>> Glad to hear that ;-) Hopefully it will graduate from the 'dream'
>> stage to some sort of implementation ;-)
>>
>> Grig
>>
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
Quick update: I've been trying to port the Java code from
simplecloud/storage but I've had mixed success. I am tempted to start
from scratch and use the Python code from the sample S3 code published
by Amazon here:
http://aws.amazon.com/code/134?_encoding=UTF8&jiveRedirect=1 . The
license is 'new BSD'. Would it be appropriate to base the libcloud S3
driver on that code and license? I would like to at least use the
authentication code from that sample.
Grig
On Thu, Nov 4, 2010 at 6:01 PM, Grig Gheorghiu <gr...@gmail.com> wrote:
> On Thu, Nov 4, 2010 at 5:57 PM, Tom Davis <to...@dislocatedday.com> wrote:
>> I like this structure, too. +1
>
> One thing with the refactoring of the directory structure is that
> tools that expect to import libcloud modules in a certain way might
> break. Not sure if that is a big concern or not.
>
>> I am also intrigued by Grig's DASH idea!
>
> Glad to hear that ;-) Hopefully it will graduate from the 'dream'
> stage to some sort of implementation ;-)
>
> Grig
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Thu, Nov 4, 2010 at 5:57 PM, Tom Davis <to...@dislocatedday.com> wrote:
> I like this structure, too. +1
One thing with the refactoring of the directory structure is that
tools that expect to import libcloud modules in a certain way might
break. Not sure if that is a big concern or not.
> I am also intrigued by Grig's DASH idea!
Glad to hear that ;-) Hopefully it will graduate from the 'dream'
stage to some sort of implementation ;-)
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Tom Davis <to...@dislocatedday.com>.
I like this structure, too. +1
I am also intrigued by Grig's DASH idea!
On Nov 4, 2010, at 7:28 PM, "Eric Woods" <wo...@gmail.com> wrote:
> +1 from me. I like this structure.
>
> libcloud/compute
> libcloud/storage
> libcloud/.....
>
> Something to consider... if the python implementation turns out anything like the Java implementation, the storage stuff will heavily leverage connection classes within libcloud/base.py. It might make sense to factor the connection classes to a common directory.
>
> - Eric
>
> -----Original Message-----
> From: Grig Gheorghiu [mailto:grig.gheorghiu@gmail.com]
> Sent: Thursday, November 04, 2010 6:42 PM
> To: libcloud@incubator.apache.org
> Subject: Re: [libcloud] Cloud storage providers/drivers
>
> 2010/11/4 Tomaž Muraus <to...@cloudkick.com>:
>> I envision splitting it into two parts - "compute" and "storage".
>>
>> So something like this:
>>
>> libcloud/
>> libcloud/
>> __init__.py
>> ...
>> compute/
>> base.py
>> providers.py
>> drivers/
>> ...
>> storage/
>> base.py
>> providers.py
>> drivers/
>> ...
>
> My vote doesn't really count, but an enthusiastic +1 from me on this
> structure ;-)
>
>>
>> Also another question about implementation arises here.
>>
>> Imo, it would be useful if we can implement the Python "File object"
>> interface, because then the storage backends could also be used with Django
>> and other libraries which rely that the "file like objects" implement the
>> File object interface.
>>
>> What do others think?
>>
>
> I think that would be very useful, yes.
>
> In fact, I am dreaming about a tool called DASH (for Data Access
> Shell), which would offer Unix-like functionality (ls, cd, du, df etc)
> for cloud storage backends. I envision typing 'dash' then 'cd
> mys3bucket', 'ls *.gif' etc. I was going to forge ahead on my own with
> it, but I thought it might be cool to actually implement such
> functionality in libcloud, and then use it in a higher-level DSL,
> which DASH would be.
>
> Grig
>
RE: [libcloud] Cloud storage providers/drivers
Posted by Eric Woods <wo...@gmail.com>.
+1 from me. I like this structure.
libcloud/compute
libcloud/storage
libcloud/.....
Something to consider... if the python implementation turns out anything like the Java implementation, the storage stuff will heavily leverage connection classes within libcloud/base.py. It might make sense to factor the connection classes to a common directory.
- Eric
-----Original Message-----
From: Grig Gheorghiu [mailto:grig.gheorghiu@gmail.com]
Sent: Thursday, November 04, 2010 6:42 PM
To: libcloud@incubator.apache.org
Subject: Re: [libcloud] Cloud storage providers/drivers
2010/11/4 Tomaž Muraus <to...@cloudkick.com>:
> I envision splitting it into two parts - "compute" and "storage".
>
> So something like this:
>
> libcloud/
> libcloud/
> __init__.py
> ...
> compute/
> base.py
> providers.py
> drivers/
> ...
> storage/
> base.py
> providers.py
> drivers/
> ...
My vote doesn't really count, but an enthusiastic +1 from me on this
structure ;-)
>
> Also another question about implementation arises here.
>
> Imo, it would be useful if we can implement the Python "File object"
> interface, because then the storage backends could also be used with Django
> and other libraries which rely that the "file like objects" implement the
> File object interface.
>
> What do others think?
>
I think that would be very useful, yes.
In fact, I am dreaming about a tool called DASH (for Data Access
Shell), which would offer Unix-like functionality (ls, cd, du, df etc)
for cloud storage backends. I envision typing 'dash' then 'cd
mys3bucket', 'ls *.gif' etc. I was going to forge ahead on my own with
it, but I thought it might be cool to actually implement such
functionality in libcloud, and then use it in a higher-level DSL,
which DASH would be.
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
2010/11/4 Tomaž Muraus <to...@cloudkick.com>:
> I envision splitting it into two parts - "compute" and "storage".
>
> So something like this:
>
> libcloud/
> libcloud/
> __init__.py
> ...
> compute/
> base.py
> providers.py
> drivers/
> ...
> storage/
> base.py
> providers.py
> drivers/
> ...
My vote doesn't really count, but an enthusiastic +1 from me on this
structure ;-)
>
> Also another question about implementation arises here.
>
> Imo, it would be useful if we can implement the Python "File object"
> interface, because then the storage backends could also be used with Django
> and other libraries which rely that the "file like objects" implement the
> File object interface.
>
> What do others think?
>
I think that would be very useful, yes.
In fact, I am dreaming about a tool called DASH (for Data Access
Shell), which would offer Unix-like functionality (ls, cd, du, df etc)
for cloud storage backends. I envision typing 'dash' then 'cd
mys3bucket', 'ls *.gif' etc. I was going to forge ahead on my own with
it, but I thought it might be cool to actually implement such
functionality in libcloud, and then use it in a higher-level DSL,
which DASH would be.
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Paul Querna <pa...@querna.org>.
2010/11/4 Tomaž Muraus <to...@cloudkick.com>:
> I envision splitting it into two parts - "compute" and "storage".
>
> So something like this:
>
> libcloud/
> libcloud/
> __init__.py
> ...
> compute/
> base.py
> providers.py
> drivers/
> ...
> storage/
> base.py
> providers.py
> drivers/
> ...
>
> Also another question about implementation arises here.
>
> Imo, it would be useful if we can implement the Python "File object"
> interface, because then the storage backends could also be used with Django
> and other libraries which rely that the "file like objects" implement the
> File object interface.
>
> What do others think?
I think providing a File object interface is useful, I'm not sure if
the 'default' mode should be that, maybe a asFileObject method?
But basically, +1.
Re: [libcloud] Cloud storage providers/drivers
Posted by Tomaž Muraus <to...@cloudkick.com>.
I envision splitting it into two parts - "compute" and "storage".
So something like this:
libcloud/
libcloud/
__init__.py
...
compute/
base.py
providers.py
drivers/
...
storage/
base.py
providers.py
drivers/
...
Also another question about implementation arises here.
Imo, it would be useful if we can implement the Python "File object"
interface, because then the storage backends could also be used with Django
and other libraries which rely that the "file like objects" implement the
File object interface.
What do others think?
On Thu, Nov 4, 2010 at 11:16 PM, Grig Gheorghiu <gr...@gmail.com>wrote:
> On Thu, Nov 4, 2010 at 2:48 PM, Eric Woods <wo...@gmail.com> wrote:
> > Hi Grig,
> >
> > We did address this in libcloud's Java initiative. After implementing a
> Java port of libcloud, we pulled SimpleCloud under the libcloud umbrella to
> provide storage, queue, and table services. Following the libcloud design
> patterns, we've implemented working adapters for Amazon S3 and Nirvanix.
> Rackspace has also expressed interest in contributing an adapter for
> CloudFiles. Take a look at the Java repository for the implementation:
> https://svn.apache.org/repos/asf/incubator/libcloud/sandbox/java/trunk/src/simplecloud/storage
> >
> > I think this would be great in the python base, too.
> >
>
> Thanks for the pointers to the Java code.
>
> So how would you envision adding storage providers to the python
> codebase? Would there be a simplecloud directory under the top
> libcloud directory, in parallel with the libcloud directory which
> contains base.py? So something like:
>
> libcloud/
> libcloud/
> base.py
> providers.py
> drivers/
> simplecloud/
> storage/
> base.py
> providers.py
> drivers/
>
> ....and then you would define the base storage classes similarly to
> the Java interfaces in simplecloud/storage/base.py, and the actual
> implementations in drivers/S3.py.
>
> Would this make sense?
>
> Grig
>
Re: [libcloud] Cloud storage providers/drivers
Posted by Grig Gheorghiu <gr...@gmail.com>.
On Thu, Nov 4, 2010 at 2:48 PM, Eric Woods <wo...@gmail.com> wrote:
> Hi Grig,
>
> We did address this in libcloud's Java initiative. After implementing a Java port of libcloud, we pulled SimpleCloud under the libcloud umbrella to provide storage, queue, and table services. Following the libcloud design patterns, we've implemented working adapters for Amazon S3 and Nirvanix. Rackspace has also expressed interest in contributing an adapter for CloudFiles. Take a look at the Java repository for the implementation: https://svn.apache.org/repos/asf/incubator/libcloud/sandbox/java/trunk/src/simplecloud/storage
>
> I think this would be great in the python base, too.
>
Thanks for the pointers to the Java code.
So how would you envision adding storage providers to the python
codebase? Would there be a simplecloud directory under the top
libcloud directory, in parallel with the libcloud directory which
contains base.py? So something like:
libcloud/
libcloud/
base.py
providers.py
drivers/
simplecloud/
storage/
base.py
providers.py
drivers/
....and then you would define the base storage classes similarly to
the Java interfaces in simplecloud/storage/base.py, and the actual
implementations in drivers/S3.py.
Would this make sense?
Grig
Re: [libcloud] Cloud storage providers/drivers
Posted by Eric Woods <wo...@gmail.com>.
Hi Grig,
We did address this in libcloud's Java initiative. After implementing a Java port of libcloud, we pulled SimpleCloud under the libcloud umbrella to provide storage, queue, and table services. Following the libcloud design patterns, we've implemented working adapters for Amazon S3 and Nirvanix. Rackspace has also expressed interest in contributing an adapter for CloudFiles. Take a look at the Java repository for the implementation: https://svn.apache.org/repos/asf/incubator/libcloud/sandbox/java/trunk/src/simplecloud/storage
I think this would be great in the python base, too.
- Eric
The Java initiative for libcloud did touch on this. We pulled SimpleCloud under the libcloud umbrella
On Nov 4, 2010, at 5:13 PM, Grig Gheorghiu wrote:
> Hello,
>
> I was wondering if there are any plans for libcloud to support various
> cloud-based storage backends, such as Amazon S3, Rackspace CloudFiles,
> etc. I think it would be an interesting addition to libcloud. I
> wouldn't mind giving S3 a shot for example. Let me know if there is
> any interest.
>
> Grig