{"issue":{"state":"closed","pull_request":{"diff_url":"https://github.com/simonwhitaker/amazon-sqs-simple/pull/3.diff","html_url":"https://github.com/simonwhitaker/amazon-sqs-simple/pull/3","patch_url":"https://github.com/simonwhitaker/amazon-sqs-simple/pull/3.patch"},"user":{"avatar_url":"https://secure.gravatar.com/avatar/edea3f8fb137277b7bd3a75f15126936?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"edea3f8fb137277b7bd3a75f15126936","url":"https://api.github.com/users/rolandwalker","login":"rolandwalker","id":727482},"milestone":null,"assignee":null,"labels":[],"updated_at":"2011-11-10T15:07:40Z","closed_at":"2011-11-10T15:07:40Z","comments":1,"url":"https://api.github.com/repos/simonwhitaker/amazon-sqs-simple/issues/3","body":"Hi Simon,\r\n\r\nThis introduces a dependency on Data::UUID.   For batch operations, the client must assign a unique ID to each subrequest.  I didn't use a simple iterator because I was thinking ahead to transparently supporting more than 10 batch SendMessage requests, calling SendMessageBatch multiple times behind the scenes.\r\n\r\nThe interface to batch operations is achieved by passing an array reference to the existing functions, which in my opinion is Perlish and elegant.\r\n\r\nWhat isn't exactly elegant is responses and error-handling.  I modified the SendResponse object to return arrayrefs for various methods in the case of batch requests.  This was before I remembered that you chose to return multiple Message objects when MaxNumberOfMessages is set.  So there are two different models of response.\r\n\r\nActually, three models if you count the responses to DeleteMessage, etc which are left as an unblessed data structure.  I didn't create response objects for all of those -- didn't know if you wanted it.\r\n\r\nError handling is complicated by the fact that batch operations return a 2xx HTTP response even if some of the sub-requests fail.  The result is that there is success/failure code in multiple packages.  I think it would be cleaner for _dispatch to return the HTTP::Response object, which would be passed to the constructor for SendResponse or Message.  But I wanted to avoid gratuitous architectural changes.","html_url":"https://github.com/simonwhitaker/amazon-sqs-simple/issues/3","title":"fully support and default to the 2011-10-01 SQS API","number":3,"id":2127124,"created_at":"2011-11-02T22:02:49Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/edea3f8fb137277b7bd3a75f15126936?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"edea3f8fb137277b7bd3a75f15126936","url":"https://api.github.com/users/rolandwalker","login":"rolandwalker","id":727482},"updated_at":"2011-11-10T15:07:40Z","url":"https://api.github.com/repos/simonwhitaker/amazon-sqs-simple/issues/comments/2696201","body":"after working with this I think it makes more sense to return an array of response objects for a batch sendmessage, consistent with receivemessage","id":2696201,"created_at":"2011-11-10T15:07:40Z"}}