Return-Path: 
 <libcloud-return-820-apmail-incubator-libcloud-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-libcloud-archive@minotaur.apache.org
Received: (qmail 22610 invoked from network); 5 Nov 2010 00:56:55 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 5 Nov 2010 00:56:55 -0000
Received: (qmail 84519 invoked by uid 500); 5 Nov 2010 00:57:27 -0000
Delivered-To: apmail-incubator-libcloud-archive@incubator.apache.org
Received: (qmail 84434 invoked by uid 500); 5 Nov 2010 00:57:26 -0000
Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:libcloud-help@incubator.apache.org>
List-Unsubscribe: <mailto:libcloud-unsubscribe@incubator.apache.org>
List-Post: <mailto:libcloud@incubator.apache.org>
List-Id: <libcloud.incubator.apache.org>
Reply-To: libcloud@incubator.apache.org
Delivered-To: mailing list libcloud@incubator.apache.org
Received: (qmail 84426 invoked by uid 99); 5 Nov 2010 00:57:26 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 00:57:26 +0000
X-ASF-Spam-Status: No, hits=0.7 required=10.0
	tests=MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [209.85.161.47] (HELO mail-fx0-f47.google.com) (209.85.161.47)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 00:57:19 +0000
Received: by fxm3 with SMTP id 3so1978701fxm.6
        for <multiple recipients>; Thu, 04 Nov 2010 17:56:58 -0700 (PDT)
Received: by 10.223.102.69 with SMTP id f5mr367781fao.107.1288918618608;
        Thu, 04 Nov 2010 17:56:58 -0700 (PDT)
Received: from [10.0.1.8] (c-67-186-134-55.hsd1.ma.comcast.net
 [67.186.134.55])
        by mx.google.com with ESMTPS id d17sm341716fav.5.2010.11.04.17.56.56
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 04 Nov 2010 17:56:57 -0700 (PDT)
References: <AANLkTi=Y1B+qQzJGwA2ns4ks9kyZpu3EzzOscXbXEMYk@mail.gmail.com>
 <5DCD0C08-5890-4FBA-A507-B7168C510856@gmail.com>
 <AANLkTi=S7Y8EB+PFjn=W-vjw5+e6hPi1Y_c1KLYHunkg@mail.gmail.com>
 <AANLkTinKdqPcS80Vjv+ovYRc4JiAumB6b4g7LJJ2_xy2@mail.gmail.com>
 <AANLkTikQMPu6Hdoo6UkzauFSLhcxetq1h2s5JudU=weC@mail.gmail.com>
 <000301cb7c77$edad6f70$c9084e50$@com>
In-Reply-To: <000301cb7c77$edad6f70$c9084e50$@com>
Mime-Version: 1.0 (iPhone Mail 8B117)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-Id: <0BF633B0-BFE5-40B2-93BC-89B77F0D32A4@dislocatedday.com>
Cc: "<libcloud@incubator.apache.org>" <libcloud@incubator.apache.org>
X-Mailer: iPhone Mail (8B117)
From: Tom Davis <tom@dislocatedday.com>
Date: Thu, 4 Nov 2010 20:57:28 -0400
To: "libcloud@incubator.apache.org" <libcloud@incubator.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org
Subject: Re: [libcloud] Cloud storage providers/drivers

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" <woodstae@gmail.com> wrote:

> +1 from me.  I like this structure.
>=20
> libcloud/compute
> libcloud/storage
> libcloud/.....
>=20
> Something to consider... if the python implementation turns out anything l=
ike the Java implementation, the storage stuff will heavily leverage connect=
ion classes within libcloud/base.py.  It might make sense to factor the conn=
ection classes to a common directory.
>=20
> - Eric
>=20
> -----Original Message-----
> From: Grig Gheorghiu [mailto:grig.gheorghiu@gmail.com]=20
> Sent: Thursday, November 04, 2010 6:42 PM
> To: libcloud@incubator.apache.org
> Subject: Re: [libcloud] Cloud storage providers/drivers
>=20
> 2010/11/4 Toma=C5=BE Muraus <tomaz@cloudkick.com>:
>> I envision splitting it into two parts - "compute" and "storage".
>>=20
>> So something like this:
>>=20
>> libcloud/
>>   libcloud/
>>       __init__.py
>>       ...
>>       compute/
>>           base.py
>>           providers.py
>>           drivers/
>>               ...
>>       storage/
>>           base.py
>>           providers.py
>>           drivers/
>>               ...
>=20
> My vote doesn't really count, but an enthusiastic +1 from me on this
> structure ;-)
>=20
>>=20
>> Also another question about implementation arises here.
>>=20
>> Imo, it would be useful if we can implement the Python "File object"
>> interface, because then the storage backends could also be used with Djan=
go
>> and other libraries which rely that the "file like objects" implement the=

>> File object interface.
>>=20
>> What do others think?
>>=20
>=20
> I think that would be very useful, yes.
>=20
> 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.
>=20
> Grig
>=20