First off, I'd like to say that I think this discussion is great, and thanks to everyone for using the mailing list for full visibility and keeping it civil :)
On May 17, 2010, at 1:50 PM, Peter Haggar wrote: > The charter (http://wiki.apache.org/incubator/LibcloudProposal) mentions > Python but does not say libCloud is Python only and will remain such. I > think it's a great idea to bring libCloud to another language like Java. It > can only help to broaden libCloud's appeal and applicability. It will also > likely broaden the libCloud community. This approach appears to be more of a breadth-first approach rather than a depth-first one. I would love to see libcloud mature as a strong framework, supporting the community with documentation and tutorials, as well as a good coverage of cloud providers near and far. Maintenance of different language ports, no matter how closely they resemble the original codebase, will undoubtedly take away from this and possibly fragment the community. We're lucky to have many participants here who aren't solely invested in Python, e.g. PHP and Java users, and somehow they continue to bridge the gap to libcloud and to provide value to the ongoing conversation. To me, it's a matter of quantity vs quality: to cover (multiple) languages and providers mediocrely, or to have fewer of both and do them well? > There are other libraries available, like jcoulds. However, that in and of > itself is not a reason to stop innovating here. One thing I think is > important is to be able to tell people to go to a single location for a > consistent provider neutral API vs. multiple places that will have different > APIs. Furthermore, choice in the market is important, so if people choose > jclouds, great, but let's not make that choice for them. Choice and competition are indeed great. Personally, the relevancy of 1) the existence of jclouds and 2) the specific language of Java are separate arguments. Yes, it would be fantastic to announce "libcloud has been ported to 18 languages and is the silver bullet for all your programmatic cloud needs" -- but I think we are pretty far away from that, and trying to move towards such a lofty goal would only hurt our ability to solidify and refine the current code base. Perhaps a similar situation is the variety of interpreters for Python (CPython, Jython, PyPy, etc) and Ruby (MRI, JRuby, Rubinus, etc). For the most part, everyone's working with a similar if not identical spec, and anyone is free to build their own interpreter, but you don't see all these interpreters rolled up and vetted by the same community. > Now, this brings up something else I wanted to get some feedback on. One > issue with libCloud is that when you want to bring it to another language, > like Java or something else down the road, it requires a port of the engine, > plus the different provider adapters. Should we consider a different > approach? For example, what if we wrote the engine in C and provided a C > interface for the APIs (reboot_node, create_node, list_images, etc). This > way I can write my code in any language and just call out to C to interface > with the libCloud library. Yes, this would require a rewrite of the exising > Python base to C, but it would put to rest the language discussions as well > as give us a single engine to maintain, vs. multiple. I think this could be > a positive step forward and really broaden the appeal of libCloud. > Thoughts? I can't speak for others but the appeal of a high-level, interpreted language such as Python has not lessened for me: ease for code maintainability, and "batteries included" advantage of tasks such as XML parsing and testing modules. To transition the core to C would take the project in a completely different direction -- favoring portability over development and maintenance of provider drivers, IMHO. All in all, I think we're at a crossroads here, and our collective efforts are best spent refining and reiterating existing code, documentation, driver support and tests, rather than getting distracted with language ports and other pies in the sky (so to speak). Cheers, Jerry
