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" <[email protected]> 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:[email protected]] > Sent: Thursday, November 04, 2010 6:42 PM > To: [email protected] > Subject: Re: [libcloud] Cloud storage providers/drivers > > 2010/11/4 Tomaž Muraus <[email protected]>: >> 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 >
