Application Development using Catalyst, Moose, Plack, DBIx::Class and other Modern Perl software!

03/17/2010

Google: Do No Evil (to Perl?)

Google is making a major update to their Adwords API, which requires significant changes to any client language bindings. These are SOAP based bindings. Although there is a a client on CPAN, this module only supports API services up to version 13, which appears to be scheduled for decommissioning on April 22nd. There is a Google developed replacement, which is not on CPAN, but on Google Code. Unfortunately this module, besides being hard to install (doesn't use the standard CPAN toolchain), doesn't support the this new API. In other words, on April 22nd SIGNIFICANT FUNCTIONALITY WILL PERMANENTLY BREAK FOR EVERY PERL APPLICATION USING GOOGLE ADWORDS API.

In the past year I believe the Perl community has made good progress in addressing the gap between how valuable and widely used our language is and how it is perceived by people outside our community. Unfortunately there is clearly still work to be done, given Google's lack of commitment. It is really surprising to have someone at Google recommend migrating away from Perl as a solution to their API change. I guess it points out how much work still needs to be done, but I have to express disappointment that such a kick in the gut is coming from Google, which has in the past been very supportive.

I realize that Google is in business to make money, not contribute free code to CPAN. I should also acknowledge that we, the Perl community, bear some responsibility for the current state of affairs. However as a company that built itself on top of open source technologies and continues to promote itself as a more open alternative to its competitors I cannot see why it is so hard to build SOAP bindings for Perl. Additionally I don't understand why Google seems so adverse to working with the standard Perl toolchain for delivering open source components (ie using CPAN.)

So... Without screaming about how we should boycott Google, start using Bing and close all our gmail accounts, how can we as a community address this problem? What would Google like to see happen in the Perl community in order to
address this gap? Who out there can help us communicate with Google and work together so that on 22 April 2010 those of us using a dynamic language with the happiest programmers, strong job demand and serious commitment to open source won't be left in the dark on 22 April 2010?

For me a reasonable solution would be a statement from Google expressing parity commitment to Perl equal to other widely used languages. Additionally I would like to see a retraction of the sentiment expressed in the linked message board. That would be a good start toward rebuilding this damaged relationship.

Comments

You can follow this conversation by subscribing to the comment feed for this post.

Ouch. All of our software which interacts with the Google AdWords API
is written in Perl. I'm surprised that a company as large as Google
would drop support for what paying customers are using, even if it's
only for a while.

Google's lack of concern about Perl and Perl developers is not really surprising. Adwords is one of the very few Google projects with supported Perl bindings and what is surprising is that they actually included Perl in the Android Scripting Environment. Also surprising are the people who think that Google will actually ever support Perl in AppEngine.The sentiment expressed in the link is about right in terms of Google and Perl, i.e. write your own or use another language. For example, try and find Perl client libraries for more than a couple of the projects listed at http://code.google.com/apis/gdata/docs/directory.html and http://code.google.com/more/ , or even acknowledgment that support for some of these APIs in Perl have been added to CPAN.I wouldn't be surprised to, one day soon, see the outdated Perl library disappear and not be replaced, as 'everyone' would have already migrated their application to a new language.

Judging from the README I think "whoever made this happen" has been battling issues with the maintenance of the perl SOAP::WSDL module.To require users to download a tarball of an unreleased branch ofSOAP::WSDL is odd enough, but to then require them to apply a patch seems very odd.Why hasn't the 'Typemap' branch of theSOAP::WSDL repository been merged into the mainline and released in the 10 months since it was created?

Maybe it's because Perl's SOAP support is simply dying, or at least falling behind the times. I really respect and appreciate the effort that the authors and maintainers of SOAP::Lite and SOAP::WSDL have put into their contributions, but I find developing SOAP apps really frustrating. I only do it when I have to.

I imagine you are not alone feeling frustrated with SOAP. The specification is complex and better suited to strongly typed languages. In general it feels like the developer community has voted REST and RESTlike apis over SOAP. I guess Google is stuck with SOAP for Adwords for legacy reasons but to be honest it blows my mind that if they are going to rewrite the API why they choose to use so many eddy SOAP features is beyond me. I think it would have been much preferable if they took a 'least common denominator' approach and used used SOAP features that are widely supported and reasonable stable.SOAP as a tool to enable web services is clearly a fail. I always felt the people working on SOAP were overly dominated by the Java crowd, no surprise Java is pretty much the only language with decent SOAP support :)

I know the guy here tasked with making this 'just work' got it so, but had to jump through a few hoops. Unfortunately we are still nowhere near able to install this simple via CPAN. Unfortunately I got pulled from this task just as I started to get rolling with it and haven't have personal time to give it (helping the wife prepare for finals, etc.) I need to catch up with where we are at.The guy I work with is telling me you will need to apply some custom patches to cpan modules which are available on the google website. Hopefully we can get Google on board with publishing stuff to CPAN soon.

Yeah none of it is on CPAN nor has there been any traction from either Google or the perl community to move this forward. FYI here are the highlight of the hoops needed to go through to get the latest and greatest version of the API and SOAP::WSDL as per the Google documentation (for the step by step see http://code.google.com/p/google-api-adwords-perl/source/browse/trunk/README):Downloaded and installed the latest library package from the Google Code site:http://code.google.com/p/google-api-adwords-perl/downloads/detail?name=awapi_perl_lib_1.3.2.tar.gzDownload and install the latest version of the SOAP WSDLmodule (now on version 861 the last time I checked BTW - Google's API dock was looking for an older version 846):http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz?view=tarpathrev=861Run the WSDL patch.Try out a test script.Having done all of this I get the following error when running the script:SOAP/Deserializer.pm did not return a true value at (eval 93) line 3. ...propagated at /usr/lib/perl5/5.8.8/base.pm line 85.BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Google/AdWords/Deserializer.pm line 24.Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Google/AdWords/Client.pm line 26.BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Google/AdWords/Client.pm line 26.Compilation failed in require at display_stats.pl line 24.BEGIN failed--compilation aborted at display_stats.pl line 24.Any help would be appreciated.

With some help from Perl Monks found the and fixed the issue (http://www.perlmonks.com/?node_id=842651): Line 24 of Google/AdWords/Deserializer.pm reads use SOAP::Lite; use base qw(SOAP::Deserializer); The code for the package SOAP::Deserializer is contained in the file SOAP/Lite.pm. In other words, there is normally no SOAP/Deserializer.pm file at least not in the current SOAP::Lite release. OTOH, base checks if there exists a package variable $SOAP::Deserializer::VERSION (which doesn't in this case), and if not tries to load SOAP/Deserializer.pm. This is all fine as long as there is in fact no such file, as the error "Can't locate SOAP/Deserializer.pm at..." would silently be ignored by base. Now, the thing is that you do seem to have such a file (as the error message indicates), and apparently one which doesn't return a true value when requireed, which is an error condition that base does not ignore... Further support for this theory is that if I put an empty Deserializer.pm file in my SOAP-Lite installation, I can reproduce the issue: $ perl -MSOAP::Lite -e'use base qw(SOAP::Deserializer);' SOAP/Deserializer.pm did not return a true value at (eval 80) line 3. ...propagated at /usr/lib/perl5/5.10.1/base.pm line 93. BEGIN failed--compilation aborted at -e line 1. Anyhow, the short version of all this is that replacing the above line (in Google/AdWords/Deserializer.pm) use base qw(SOAP::Deserializer); with BEGIN { our @ISA = "SOAP::Deserializer"; } should also fix the issue...I have edited the module and I no longer am getting a compilation error.

I did add it as a comment to my the AdWords forum post but did not send anything out the the mailing list(s). Since I am finding that there are more problems with the code even though its now compiling I figured I would compile the list of problems and solutions I encounter as I go along into one document and then circulate it around.