Ensure modules are API "version aware"

Modules will be able to pick their API version by parameter. The change in SQS API is determined by what API you specify. That should be, along with every other option, passed on to the module developers.

The old SQS had a REST and SOAP API. The new version no longer has the REST API but instead has the Query API. With both the Query API and the SOAP API you specify the WSDL version.

See: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=114...

Going through your ec2 module I've noticed you have put the API into the hands of the end user as an admin option and not let the modules that will be extending the service control the API.

One of the most important goals I have for these modules if for them to offer the complete service to the module developers. I don't want to dumb down the service in any way. If the module developers do not have the full power and features of the service, these modules will be useless and will not be used. ALL features and functions of the services should be able to be controlled these modules. These modules are here just to lighten the load of the developer not hinder them.

That being said, I do see a market for easier use of some of these services. But I believe those are better left to other modules that extend these modules. For example I plan to write a S3 Simple module that will use the S3 API with a really easy to use system and interface. Obviously that will dumb down the service and full features won't be available but that module will be extending this module.

I am basically agreeing with your original post. For example, a function from your aws_ec2.module:

function aws_ec2_createKeyPair($keyName) {
  $host = variable_get('aws_ec2_host', 'ec2.amazonaws.com');
  $request = array(
    'Action' => 'CreateKeyPair',
    'KeyName' => $keyName,
    'Version' => variable_get('ec2_api_version', '2007-08-29'),
  );
  return aws_queryRequest($host, $request);
}

In this function the Amazon API version is delegated to the end user of the module and affects all modules that extend it. The API version, along with ALL of features of the service, should be available to the extending modules. In this example, that means there needs to be a way to set the API version in the function parameters.

The API version doesn't matter to the end user much. I would either take out the admin option to set the API version or change it to be a Default API version that extending modules will be able to override. I have done this for S3 with a default bucket.

No problem simonc. I have been busy myself and have not been able to put much time in lately.

The 2.0.x version of this module allows for a specific API version to be chosen for each service.