first outside contribution (of code)!

[Alex Polvi]

Team,

Just wanted to point out that jcsalterego was the first outside code
contributor to libcloud! Thanks jcsalterego!

The commit: http://github.com/cloudkick/libcloud/commit/72d2e24d037b902098619d4cae5af974dece9ffd

PS: I also have began to move stuff around. The first major thing was
src/ -> py/, and I added a rb/ directory with a teaser README. There
has been a lot of talk about a ruby port of libcloud, so I thought I
would make room. :)

-Alex

--
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624

[Tom Davis]

There has been a lot of talk about a ruby port of libcloud, so I thought I would make room. :)

You wouldn't put the Python and Ruby libraries in the same code tree, so why convolute the directory structure just to provide a single README indicating a desire for a Ruby version of the project?

[Alex Polvi]

On Mon, Jul 27, 2009 at 8:19 AM, Tom Davis<t...@dislocatedday.com> wrote:
>> There has been a lot of talk about a ruby port of libcloud, so I thought I
>> would make room. :)
>
> You wouldn't put the Python and Ruby libraries in the same code tree, so why
> convolute the directory structure just to provide a single README indicating
> a desire for a Ruby version of the project?

Actually, I was thinking we would have them in the same tree ... we
would need to move setup.py and test into py/ as well.

-Alex

[Tom Davis]

I feel like that would add unnecessary complexity to both the structure and development process.

Presumably, the same people working on the Python version would not work on a Ruby version, so why would the same core developers handle patches and pulls and issues for two separate languages at once? I can understand the desire for a Ruby implementation (even if the language disgusts me), but I think having them in the same library really isn't the way to go.

Unless you or your team are planning to simultaneously develop and vet both implementations, I strongly feel it should be handled under another project. What was the last library you found that including implementations in different languages under the same source tree? There's a reason there aren't [m]any.

[Alex Polvi]

OK -- did you prefer 'src/' ?

Also, are you working on any of the interfaces? I started to create
some bugs ... let me know if you're working on anything.

http://github.com/cloudkick/libcloud/issues

-Alex

[Tom Davis]

You can see my preference on my fork here: http://github.com/tdavis/libcloud/tree/master

I am working on the interfaces in question right now. I guess I can't claim issues (never used GitHub issues before)? I will just make a note in them...

[Alex Polvi]

OK -- I "assigned" them to you by applying a newly created "tom-davis"
tag. You should be able to "request pull" (or merge or something) when
you are ready. Looking forward to it!

-Alex

[Alex Polvi]

Also, if you put "closes #1" in your commit msg, it will cause that
bug to be closed when the merge happens. Just a heads up!

-Alex

[Tom Davis]

Sweet, good to know!

[Alex Polvi]

On Mon, Jul 27, 2009 at 10:03 AM, Tom Davis<t...@dislocatedday.com> wrote:
> You can see my preference on my fork here:
> http://github.com/tdavis/libcloud/tree/master
>
> I am working on the interfaces in question right now. I guess I can't claim
> issues (never used GitHub issues before)? I will just make a note in them...

Any luck? Would love to see what you came up with, even if it is just
on a dev branch or something.

[Tom Davis]

Some of us have startups to work on, you know! ;)

Just pushed some commits to my fork: http://github.com/tdavis/libcloud/commits/master

The IDriver is still very much in the development stage, but IConnection and friends are pretty solid. I'll probably be editing them, though, to add some suitable callbacks for stages in the request cycle. You'll notice I removed list_servers (and synonyms like describe_instances) because these aren't really a function of the connection.

[Alex Polvi]

Tom, thanks for pushing this stuff out. I'm still not entirely clear
on what your vision. Maybe implement the dummy provider with your
"plan", and we can go from there?

In the mean time, jcsalterego has contributed a few more functions to
slicehost (reboot and destroy!). Thanks jcsalterego!

-Alex

[Tom Davis]

Once the interfaces are finalized and the base classes are done, I think you'll get the idea. A lot of it stems from practices used in Twisted because I've spent a lot of time living in that code and I quite like how it's setup. Checkout their implementations of Protocols, Transports, Factories and the like to see where (and whom) I'm basing this off of. Of course, this isn't nearly as complicated (we're not building our own asynchronous tcp transports and so on), so it should be more straight forward to grok than Twisted's sophisticated-yet-tangled web.

The ultimate goal here (for me, anyway) is to get a great foundation laid out so that implementing an actual driver can be done in a day or two, with the peace of mind that said driver completely conforms to our API, is properly tested, etc. Of course, it will take a little while to get there :)

[Alex Polvi]

On Tue, Jul 28, 2009 at 12:48 PM, Tom Davis<t...@dislocatedday.com> wrote:
> Once the interfaces are finalized and the base classes are done, I think
> you'll get the idea. A lot of it stems from practices used in Twisted
> because I've spent a lot of time living in that code and I quite like how
> it's setup. Checkout their implementations of Protocols, Transports,
> Factories and the like to see where (and whom) I'm basing this off of. Of
> course, this isn't nearly as complicated (we're not building our own
> asynchronous tcp transports and so on), so it should be more straight
> forward to grok than Twisted's sophisticated-yet-tangled web.
>
> The ultimate goal here (for me, anyway) is to get a great foundation laid
> out so that implementing an actual driver can be done in a day or two, with
> the peace of mind that said driver completely conforms to our API, is
> properly tested, etc. Of course, it will take a little while to get there :)

Here here! I'm excited to see what your implementation ends up like.
Let me know if you have any questions about the current design.

In the mean time, I'm messing with other bits of the code,

-Alex

[Paul Querna]

On Jul 27, 7:13 pm, Tom Davis <t...@dislocatedday.com> wrote:
> Some of us have startups to work on, you know! ;)
>
> Just pushed some commits to my fork:http://github.com/tdavis/libcloud/commits/master
>
> The IDriver is still very much in the development stage, but IConnection and
> friends are pretty solid. I'll probably be editing them, though, to add some
> suitable callbacks for stages in the request cycle. You'll notice I removed
> list_servers (and synonyms like describe_instances) because these aren't
> really a function of the connection.

IConnection seems to mostly make sense, but I have two questions:

1) Why have both secure and insecure? It seems there is very little
value in ever supporting 'insecure' in any API and we would
automatically use the most secure method available for any API -- I
would propose just eliminating the choice in the interface, and
encourage everything to default to the most secure methods/signatures/
transports available.

2) Why is connect() exposed? Requests can be pipelines, or not, or
connections closed, they might be over IP/TCP/HTTP, or something
completely different, but in a stateless http world, I don't think
connnect() needs to be exposed -- maybe really its just looking for a
validate_connection() so you know the basic transport is up and
running before doing too much work.

Thanks,

Paul

[Sam Johnston]

On Thu, Jul 30, 2009 at 8:05 AM, Paul Querna <paul....@gmail.com> wrote:

IConnection seems to mostly make sense, but I have two questions:

1) Why have both secure and insecure?  It seems there is very little
value in ever supporting 'insecure' in any API and we would
automatically use the most secure method available for any API -- I
would propose just eliminating the choice in the interface, and
encourage everything to default to the most secure methods/signatures/
transports available.

There are certainly cases where encryption is neither useful nor desirable... internal deployments and encryption export restricted zones for example. When designing interfaces you should never (well, rarely) say never.
 

2) Why is connect() exposed?  Requests can be pipelines, or not, or
connections closed, they might be over IP/TCP/HTTP, or something
completely different, but in a stateless http world, I don't think
connnect() needs to be exposed -- maybe really its just looking for a
validate_connection() so you know the basic transport is up and
running before doing too much work.

Where there are sessions there is a connection model - one can "connect" and "disconnect" (the generic equivalents of "login" and "logout"). Such functions are useful when you start talking about connection pooling and so on...

In any case this function can do nothing for APIs that need nothing done, or called implicitly where appropriate (that is, there should be no harm done by leaving it here).

Sam

[Tom Davis]

FWIW, it isn't there for users. In fact, a Connection should never be used directly at all! I'd planned to validate the connection in Connection.request(); if a connection weren't established, call Connection.connect() before making the request. This way we aren't needlessly connecting to anything on instantiation, too.