Hello, Ruby developers! First of all, I'd like to thank you! I've been getting some good feedback from you in the form of bug reports, and am currently working on the next iteration of the Ruby client library. Some of the major changes planned are:
- Creating an abstraction layer for API objects, to avoid using soap4r objects directly in user code. This will allow for a move away from soap4r and towards more Ruby-like and 1.9-compatible SOAP toolkits in the future. - Reworking the authentication / authorization portion of the client library, to allow for different auth methods. - Reworking v2009/v2010 error handling, to fit the API model more closely. - A move towards more Ruby-like method/property names (deprecating the camelCase names which are automatically generated from the WSDLs, and moving towards underscore_separated names). The first point is especially important, as it will address a number of current concerns: - Due to the necessities of supporting multiple API versions, soap4r objects currently live inside deep namespaces, which include the version and service. This makes it hard to avoid embedding the API version into your code, and thus can require frequent changes to your codebase, with each new API version. - soap4r objects don't follow Ruby expectations, like the ability to do duck typing (for example, you can't use a Campaign object from the CampaignService in the BulkMutateJobService, even though they're identical). - soap4r is flaky with using hashes instead of the statically- generated objects; sometimes it works, sometimes it doesn't. It all depends on seemingly arbitrary rules. Creating this layer correctly, however, involves some pretty important choices, and I'd like your feedback on this. I can envision two options to solve this problem: - Moving towards nested hashes as the de-facto way of creating the API "objects", similarly to what is currently done in the Python client library (example at http://code.google.com/p/google-api-adwords-python-lib/source/browse/trunk/examples/v201003/add_campaign.py ). This is a beautifully dynamic and simple option, but does have somewhat of an awkward syntax (although that could be improved with some creative usage of metaprogramming). In addition, and more importantly, you'd lose the ability to inspect objects and see what properties they contain, effectively forcing you to rely on the documentation, and possibly limiting the use of certain reflexion- based tools. - Creating a single set of static classes that would encompass the entire list of supported properties across all versions; that is, if an object A has properties a and b in version 1, and properties b and c in version 2, the static class would support a, b and c. Although slightly awkward, this way there could exist a single Campaign object that would work across any version or service, with the appropriate changes. Runtime validations would still exist to check if you're using the wrong property for a certain version. So, the question is: how important is it to you to have static, plain Ruby classes in your code, that you can inspect with reflection? Would a dynamic approach strike you as a better fit with your development model and the Ruby "way"? I'd love to get your feedback on any of the items above, as well as any other suggestions you might have for client library improvements! --Sérgio Gomes, AdWords API Team -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
