Amazon EC2 client library and sponsored CPAN work

This project work is to develop Amazon::EC2 a portable client library for working with and managing Amazon Elastic Computing Cloud (EC2) services under my guidance. I've been a Perl for over a decade. I have an itch I need scratched, but my fingers are all busy. I am willing to put a bit of money in to seeing this work become available sooner rather then later. I intend on releasing this work in to CPAN under the Artistic license. Please bear that in mind in your bid's pricing. ## Deliverables This project work is to develop Amazon::EC2 a portable client library for working with and managing Amazon Elastic Computing Cloud (EC2) services under my guidance. I've been a Perl for over a decade. I have an itch I need scratched, but my fingers are all busy. I am willing to put a bit of money in to seeing this work become available sooner rather then later. I intend on releasing this work in to CPAN under the Artistic license. Please bear that in mind in your bid's pricing. Why not Net::Amazon::EC2? There are a couple of big "show stoppers" IMHO in that library for my uses that I believe an alternate means of work with EC2 services is needed. * Procedural interface rather then OO interface. The code requires a lot of strings be repetitively around that IMHO seems unnecessary and awkward way of working with the services. * Net::Amazon::EC2 now uses Moose which seems lovely, but the pre-requisites and installation of it are far too extensive and heavy IMHO if you are writing redistributable software using it. This library should be complementary and work like (and borrow heavily) from Amazon::S3 and AmazonSimpleDB. (SimpeDB is under construction and in need of an API refactoring.) * [login to view URL]~tima/Amazon-S3-0.441/ * [login to view URL]~tima/Amazon-SimpleDB-0.03/ CPAN module I have identified for use in this library: * LWP::UserAgent::Determine * XML::Simple * Class::Accessor::Fast * Task::Weaken (I think) * URI This is not a comprehensive list, just what I've identified and prefer be used. I have stubbed out all the files with fairly complete POD documentation. It's not entrely complete, but I think a pretty good start in getting the task at hand defined and work started. In addition to the client library itself, I expect a comprehensive test suite be developed including podcoverage tests when run by the developer. See Amazon::S3 for examples in how to test AWS services. Price is not the only deciding factor. RAC work ratings and number of previous projects will also be considered. Previous CPAN contributions a big plus. Please list them in your response if you have them. Submissions without a specific price will be ignored. Existing Amazon Web Services knowledge is preferred. Any AWS expenses are your own reponsbility. These expenses should be quite small in the the scheme of thigns. MISC NOTES The goal of this work is NOT to create a full implemented working library, but a start for the core functionality that can be enhanced and improved of addition iterations. Currently EC2 features such as security groups are not being implemented. Others like product codes, key pairs and availability zones are only roughed in. Currently a developer cannot get at the underlying HTTP responses between the client library and the EC2 API web service. This will be addrssed in later phases. Use of SAX is an absolutely requirement. I despise libraries or solutions that are tied to one specific XML parser. Use of XML::Simple makes that pretty transparent and easy. Please pass the code through the attached perltidy config file before submitting code to review. This will will help me read it over and give feedback. I like and expect clean scannable code. See Amazon::S3 and Amazon::SimpleBD for examples of my system. Note that the former is under construction and may not be clean as I'd like yet. In fact I hate the interfaces use of response objects for everything and plan on overhauling the interface. Assume all accessors are read only. For the most part they are be set when then object is instantiated using the new method. The new method should not be called be the typically developers, but is used extensively by the Amazon::EC2 methods themselves. Err on the side of low net traffic calls. Lazy fetching or instantiation of objects and caching data locally is preferred if possible. Look out for circular references and use weaken as necessary. For instance, volume and instance could have references to each other stored in which case neither object could potentially never go out of scope in a persistent environment. Look at XML::Elemental for more on this issue. Please add sensible synopsis code in POD as you go. If a class is simple a data container and a synopsis seems unnecessary remove that section from the PODs.