+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
