Friday, March 26, 2010

[Gd] Google Chrome Developer Update - Geolocation and Incognito Extensions

| More

Chromium Blog: Google Chrome Developer Update - Geolocation and Incognito Extensions

What's New in Google Chrome?

The Google Chrome Dev channel has been updated to 5.0.356.2 for all platforms since our last developer post. It includes a few new goodies for developers:
Please keep in mind that these features are still under development and are not 100% stable yet. In addition to the above, there are a few new experimental features baking in /trunk. You can try them out with the --enable-experimental-extension-apis flag:
Samples and Tutorials

We’ve added a few new sample extensions tutorials to get you started:
  • Sample and tutorial to demonstrate using Google Analytics in your extensions
  • Extension to display, create, and update your Google Documents
  • Tutorial to demonstrate using OAuth in your extensions
Remember to follow us on Twitter: @ChromiumDev!

Posted by Eric Bidelman, Developer Advocate

[Gd] Beta Update: Finally a Chrome 5 Beta for Windows

| More

Google Chrome Releases: Beta Update: Finally a Chrome 5 Beta for Windows

Google Chrome 5.0.342.8 has been released to the Beta channel on Windows. 

There's not much to report because most of the features were released previously in Chrome 4.1. This release does have an option in the Under the Hood section to let you disable automatic translations. 

Now that all Beta users are on the same revision, we can disclose the following security issues fixed in this release:

  • [36553Low Don’t store non-text fields in the local Web Data database. Credit to Florian Rienhardt, BSI.
  • [Linux only] [36770High Certificate checking error. Credit to Hironori Bono and Adam Langley of the Chromium development community.
To get on the Beta channel, you can download Google Chrome fromIf you find issues, please let us know:

--Mark Larson, Google Chrome Team

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 5.0.360.0 for Windows, Mac, and Linux platforms

  • Tabbed bookmark manager (Issue 4890)

  • Several Translate improvements

  • Fixed several AutoFill features (Issues 38218, 38009, 38538, 38104, 38681)

  • Fixed long timeout when navigating away from slow pages (Issue 11007)

  • Linux
  • Fixed menu popups for Xinerama users (Issue 14184)

  • Better crash dumping

  • Security
  • Updated libpng for CVE-2010-0205

  • Known Issues
  • Issue 39196 Bookmarks under the chevron are disabled (fixed but not in this release)

  • Issue 39104: REGRESSION: Native dialogs got extended - fixed on trunk.

  • Issue 37874: REGRESSION: Visual Defect / Gray Bar on Frame and Superbar on Windows 7 and Vista Aero

  • Issue 39340: [Extensions] Chrome crashes when dragging browser action not-incognito-enabled from normal window to incognito window

  • Issue 39360: [Extensions] Facebook for Google Chrome extensions doesn't work in incognito mode

  • Issue 39372: [Extensions] new tab extensions takes effect in incognito mode even without "Allow this extension to run in incognito" option checked.

  • More details about additional changes are available in the svnlog of all revisions.

    You can find out about getting on the Dev channel here:

    If you find new issues, please let us know by filing a bug at

    Karen Grunberg 

    Google Chrome 

    [Gd] New Google Apps Marketplace YouTube channel full of vendor videos

    | More

    Google Apps Developer Blog: New Google Apps Marketplace YouTube channel full of vendor videos

    We launched the Google Apps Marketplace only a couple of weeks ago with great apps available from 50+ vendors. More than a dozen of these vendors have not only developed great apps and integrated them with Google Apps, but have also created some entertaining videos. Today we're launching a new YouTube channel at to showcase these videos.

    Here's a playlist of the videos, but you should visit the channel for the full experience:

    If you haven't already launched an app on the Marketplace, visit to learn how to integrate with Google Apps. After you've published your app on the Marketplace, let us know if you've created a great video that showcases the app and its capabilities and we may feature it on the new YouTube channel.

    Posted by Ryan Boyd, Google Apps Marketplace Team

    Thursday, March 25, 2010

    [Gd] Beta Update: Translate for the Mac

    | More

    Google Chrome Releases: Beta Update: Translate for the Mac

    Google Chrome 5.0.342.7 has been released to the Beta channel for Mac users (we released Linux yesterday). The highlights for Mac are basically the same, with the addition of Full Screen view working.

    We finally have automatic translation for all Beta users.

    • Automatic translations and greater control over content for privacy. The Google Chrome 4.1 Beta announcement for Windows explains these features in more detail.
    • Full screen mode
    • Really, really reload. A normal reload causes the browser to check with the server before reusing its cached content.  The server can decide whether or not the browser should use its cached content.  A force reload causes the browser to ignore its cached content and ask the server for a fresh copy of the page. Use Shift+Reload to force a reload (the reload keyboard shortcut varies by platform).
    To get on the Beta channel, you can download Google Chrome from

    If you find issues, please let us know by filing a bug.

    --Mark Larson, Google Chrome Team 

    [Gd] Novell Pulse and Google Wave: Demonstrating Inter-company Collaboration

    | More

    Google Wave Developer Blog: Novell Pulse and Google Wave: Demonstrating Inter-company Collaboration

    Ian Roughley is an architect on Novell Pulse, a new real-time collaboration environment for enterprises that federates with Google Wave so users of both products can work together using their tool of choice.

    For Novell Pulse, it was a pretty easy decision to adopt the Google Wave Federation Protocol. For many months before Google Wave was announced to the world, we had been working on solving exactly the same problems: how to collaborate instantly and on‑demand; how to make collaboration easier for groups; how to expedite document workflow; and how to do it all in real‑time. We had also come to many of the same conclusions, and if you look at the products side‑by‑side you can see this reflected through the interfaces. Not exactly, but certainly the big decisions.

    The Google Wave Federation Protocol excited us, because for the first time since email, it provided a way for collaboration systems to cooperate in a non‑silo'dway . The promise is that each organization can choose what product to use and the communication will flow unimpeded between the different systems, in the same way that people on different email systems can send and receive messages to each other today. This is a collaboration revolution we wanted to be a part of.

    From a technical perspective we've leveraged the code Google has open sourced by integrating Google Wave's operational transformation algorithm and the federation parts of the FedOne implementation into Novell Pulse. This allowed us to quickly get the core federation protocol features working. We have developed our own editor, which provides compatibility with a large number of browsers, and provided a mapping from the Google Wave Conversation Model to our own internal structure. Along with the Google Wave Federation Protocol, we also support the Wave Gadgets API and are working to support the Wave Robots API. This allows extensions built by 3rd parties to work seamlessly with a mix of users on Novell Pulse and Google Wave.

    Check out this video to see a business use-case of federation between Novell Pulse and Google Wave.

    We're excited about the opportunities for open collaboration that utilizing the Google Wave Federation Protocol will bring to both the users of Novell Pulse and Google Wave, as well as a growing ecosystem of extension developers that now have broader distribution opportunities. For more information on Novell Pulse, visit

    Posted by Ian Roughley, Architect, Novell Pulse

    [Gd] GWT Community Updates

    | More

    Google Web Toolkit Blog: GWT Community Updates

    It's been a while since we've put together what's been going on in the GWT community, and there's no time like the present to do so. Below are a handful of updates and new releases that have taken place over the past few months.

    Smart GWT 2.1: Smart GWT, a framework that provides enhanced widgets that can coexist on both your client and server, has released a 2.1 version. Below are some of the key features of this release:

    • GWT 2.0.3 compatible

    • New Graphite theme

    • Support for widgets in ListGrid cells

    • Support for Checkbox TreeGrid with cascade selection and tri-state checkboxes (selected, unselected, partial)

    • Significant improvement in ToolStrip appearance

    • Improved Print support with fine grain control over what widgets and data appears in print view

    • Support for Flash, ActiveX, Applets and SVG as Smart GWT widgets

    • Various performance improvements

    GWT Designer 7.3: Instantiations announced an upgrade to version 7.3 of its popular graphical user interface (GUI) building product, GWT Designer™. GWT Designer v7.3 stays in sync with the major new release of the open source Google Web Toolkit (GWT) version 2.0, adding support for the new GWT 2.0 Development Mode, Layout Panels, Widgets and more. The upgrade includes the following features:

    • GWT 2.0 Development Mode Support – provides the ability to debug your project with the browser of your choice. Includes multi-browser debugging, allowing you connect to multiple browsers in a single debugging session and network support, plus a view to embed development mode logging messages directly into an Eclipse view.

    • Layout Panels - Employ all new GWT 2.0 Layout Panel types. Layout Panels offer a predictable, constraint-based layout system on top of standard CSS to help you reliably create a desired layout.

    • Widgets - Enjoy greater design flexibility with support for all new GWT 2.0 in-line widgets (Label, HTML and Hyperlink).

    • Enhanced Ext GWT (GXT) Support – Utilize added support for GXT 2.1 and un-typed GXT events.

    RaphaelGWT: The Hydro4GE team has open sourced their RaphaelGWT project. RaphaelGWT allows you to integrate GWT with Raphael, a lightweight JavaScript library for cross-platform vector graphics.

    Gilead Update: Gilead, an Open-Source framework for seamless integration of Hibernate and GWT, has released an updated version of its project that contains the following features:

    • Predefined remote services

    • A new specific transport annotation (@LimitedAccess) to implement custom access to entity fields (role based for example)

    • Lazy property checking on the GWT side, to know if a null association on client side was already null on server or just lazy but not loaded (and thus replaced with null by Gilead)

    • A ConfigurationHelper class, to limit Gilead configuration to one line of code

    GWT MVC 0.4: The GWT MVC project, aimed at creating a layer on top Google Web Toolkit's widget library capable of implementing RIAs in easier and more conceptually guided way based on Model-View-Controller design pattern, has released version 0.4.

    GWT Service Resolver: The gwtserviceresolver project has been added to Google code. Similar to gwt-dispatch, gwtserviceresolver allows you to minimize the code changes that are necessary as you add new RPC services.

    GWT Mosaic: The GWT Mosaic project has added some tutorials to help developers wire up UiBinder-based elements with GWT Mosaic Actions.


    [Gd] Migration made easier

    | More

    iGoogle Developer Blog: Migration made easier

    Last year we released a legacy migration guide for converting legacy gadgets to gadgets.* by hand. At the time, we promised a migration tool to help perform these migrations automatically.

    Today, I’m happy to announce the legacy gadget migration tool, which will convert existing XML and JavaScript code to use the gadgets.* API. The tool will accept raw XML and JavaScript to convert, or a publicly visible URL, read the code, and replace references to the legacy API with their gadgets.* equivalents. In the rare case where a migration cannot be automatically performed, it will output per-line warnings indicating what changes developers must make by hand, along with a relevant link to the migration guide.

    Of course, please test migrated code before deploying to all of your users.

    If you have any questions, please inquire in the iGoogle Developer Forum.

    Posted by Dan Holevoet, Developer Programs

    [Gd] App Engine SDK 1.3.2 Released

    | More

    Google App Engine Blog: App Engine SDK 1.3.2 Released

    Today we are excited to announce the release of version 1.3.2 of the App Engine SDK for both the Java and Python runtimes. 1.3.2 includes a number of changes and bug fixes.

    For this release, we have concentrated on removing a number of limitations that have been affecting developers:

    • Blobstore API - A new method (fetch_data for Python, fetchData for Java) allows your application to request the contents of a Blob from within your application’s code.
    • URLFetch API - We’ve expanded the number of ports you can access with the URLFetch API. You can now access ports 80-90, 440-450, and 1024-65535.
    • Mail API - We’ve expanded the allowed mail attachments to include common document extensions including .doc, .ppt, and .xls.
    • Task Queue API - We’ve increased the maximum total Task Queue refill rate to 50 per second.

    We’re also happy to announce, based on your feedback, a new Denial of Service (DoS) blocking system in App Engine. This system allows you to blacklist specific IP addresses from accessing your application, and to prevent them from costing your application money or eating up your quota. You can also view the top IPs that have accessed your application in the Admin Console, to help you figure out what IPs you may want to block. More information on this feature is available for Python and Java.

    There’s a lot of other changes and fixes in this release, including a new Java version of the Appstats profiling tool, so read the release notes (Python, Java) for a complete list of changes and download the new versions of the SDK.

    Posted by The App Engine Team

    [Gd] Discover v2009: Do more with mutate

    | More

    AdWords API Blog: Discover v2009: Do more with mutate

    In previous versions of the API, services had separate methods for adding, updating, and removing items in an AdWords account. The v2009 version changed this paradigm and combined the functionality into a single method called mutate. The mutate method works on operations, where each operation defines the action to perform (operator) and the item to perform it against (operand).

    While it may not be immediately obvious, the mutate method is designed to process many operations in one call. For example, the following method uses the PHP client library to add multiple keywords in one request.

    function addKeywords($keywords, $adGroupId, $adGroupCriterionService) {
    $operations = array();

    foreach ($keywords as $keyword) {
    // Create biddable ad group criterion.
    $adGroupCriterion = new BiddableAdGroupCriterion();
    $adGroupCriterion->adGroupId = $adGroupId;
    $adGroupCriterion->criterion = $keyword;

    // Create operation.
    $operation = new AdGroupCriterionOperation();
    $operation->operand = $adGroupCriterion;
    $operation->operator = 'ADD';

    // Add operation to array.
    $operations[] = $operation;

    // Make mutate request.
    $results = $adGroupCriterionService->mutate($operations);

    return $results;

    It’s important to note that performing multiple operations in one request can be substantially faster then performing them one at a time. Making any request to the AdWords API comes with a certain amount of overhead, so performing more work per request can dramatically improve the performance of your application. For example, in a simple test I ran adding 500 keywords in a single request was over 100x faster than performing 500 separate requests.

    Also of note is that the operations in a mutate request can contain any mixture of operators and span any number of campaigns, ad groups, etc. That means you can add a keyword to one ad group and update a keyword in a different ad group in the same request.

    More information on the mutate method of a service and the operations it supports can be found in the developer documentation, and any questions you have can be posted to the forum.

    - Eric Koleda, AdWords API Team

    [Gd] Making Google Calendar Applications Faster: Partial Response and Update

    | More

    Google Apps Developer Blog: Making Google Calendar Applications Faster: Partial Response and Update

    Sometimes you’re only interested in specific elements from a Google Data API feed. With most APIs, you typically have to retrieve the entire feed and parse out the individual required elements. This can be very expensive for some applications-- especially mobile apps with limited bandwidth.

    We recently launched the partial response and update feature for the Google Calendar Data API. Partial response and update allows you to request and update feeds containing only the elements that you’re interested in.

    To request a partial response, you’ll need to add the fields query parameter to the end of the feed URL.

    <?xml version="1.0" encoding="UTF-8"?>
    <feed xmlns="" xmlns:gd="">
    <title type="text">Example meeting</title>
    <gd:when endTime="2010-03-25T09:00:00.000-07:00" startTime="2010-03-25T08:00:00.000-07:00">
    <gd:reminder method="alert" minutes="10"/>
    <gd:reminder method="sms" minutes="10"/>
    ... more entries ...

    To partially update a feed, you simply need to modify the partial request with your updates and submit it back to the server using HTTP PATCH. The HTTP PATCH method prompts for the requested changes to be applied to the resource defined by the request URL. To remove elements, partial updates can use the gd:field attributes, which specifies elements to remove before merging with the target source. The example below updates the event title and time.

    PATCH HTTP/1.1
    Content-Type: application/xml
    GData-Version: 2
    If-Match "FE8LQQJJeSp7IWA6WhVa"
    <?xml version="1.0" encoding="UTF-8"?>
    <title type="text">Example meeting update</title>
    <gd:when endTime="2010-03-27T10:00:00.000-07:00" startTime="2010-03-27T09:00:00.000-07:00">
    <gd:reminder method="alert" minutes="10"/>
    <gd:reminder method="sms" minutes="10"/>
    As you can see, the ability to partially request and update feeds greatly reduces the amount of data transferred, which is especially important in the mobile world.

    For documentation on Google Calendar partial response and update, please refer to our Developer’s Guide.

    We’ve also launched partial response and update for the YouTube Data API and Picasa Web Albums Data API and partial retrieval for the read-only Sidewiki Data API. For full details, please refer to our post on the Google Code Blog.

    Posted by Peng Ying, Google Calendar API Team

    Wednesday, March 24, 2010

    [Gd] [Search][Release] Video Search excluding YouTube fixed.

    | More

    Google AJAX API Alerts: [Search][Release] Video Search excluding YouTube fixed.

    Fix for Video Search not returning YouTube results.

    [Gd] Beta Update: Translate for Linux, SSL fix

    | More

    Google Chrome Releases: Beta Update: Translate for Linux, SSL fix

    Google Chrome 5.0.342.7 has been released to the Beta channel for Linux.

    We’ll be releasing 342 to Mac and Windows soon, but we wanted to get the Linux update out as quickly as possible to fix an issue with Google SSL sites failing with ‘error 107 (net::ERR_SSL_PROTOCOL_ERROR)’ (issue 37722).

    Here are the highlights since the 307.11 update:
    • Automatic translations and greater control over content for privacy. The Google Chrome 4.1 Beta announcement for Windows explains these features in more detail.
    • Really, really reload. A normal reload causes the browser to check with the server before reusing its cached content.  The server can decide whether or not the browser should use its cached content.  A force reload causes the browser to ignore its cached content and ask the server for a fresh copy of the page. Use Shift+Reload to force a reload (the reload keyboard shortcut varies by platform).
    To get on the Beta channel, you can download Google Chrome from

    If you find issues, please let us know:

    --Mark Larson, Google Chrome Team 

    [Gd] How Atlassian integrated with Google Apps - Part 1

    | More

    Google Apps Developer Blog: How Atlassian integrated with Google Apps - Part 1

    Editor's note: This post was written by Richard Wallace of Atlassian. This is part one of a two-part series on Atlassian's recent development for the Google Apps Marketplace. Atlassian's JIRA Studio is a hosted software development suite, combining Subversion source control, issue tracking, wiki collaboration, code reviews and continuous integration. JIRA Studio is now integrated with Google Apps and is featured in the Google Apps Marketplace - a great tool for development teams using Google Apps. This series explores some of what Atlassian worked on, and what they learned along the way.

    Part 1: Nine cool things you can do with the JIRA Studio Activity Bar

    By now you have probably heard about the Google Apps Marketplace and JIRA Studio integration. If not, the short version is that Google has created a place for users of Google Apps to sign up for third party hosted SaaS offerings and have them fully integrated with their Google Apps domain. Google was kind enough to ask Atlassian if we would be interested in integrating our hosted agile development suite, JIRA Studio, for their initial offering, and we thought it would be an awesome opportunity. So, if you purchase JIRA Studio through your Google Apps account you get issue tracking and project management, a wiki, source code repository and review system, and (optionally) a continuous integration server configured out of the box, using the same user accounts as your Google Apps for authentication.

    However, we decided that just stopping at Single Sign On (SSO) integration, while cool, wasn't enough. Google provides a rich set of APIs for accessing your Google Apps data, so we wanted to provide a better experience for anyone who purchased JIRA Studio. So, while a team in Sydney worked on the authentication integration bits, a second team worked on the "cool" features. A few of the more obvious cool things were Google Doc macros in the wiki, attaching Google Docs to JIRA issues and so on. But we wanted something that would really stand out.

    The one Google App that we hadn't found a way to integrate yet was Google Talk. Someone suggested implementing a chat client similar to the one you get in Gmail that would appear on every page in Studio. We quickly came to realize it didn't need to be limited to just chat, it would also have tabs showing various bits of information from JIRA Studio and Google Apps. And so the JIRA Studio Activity Bar was born.

    The feature we delivered does a lot. With the JIRA Studio Activity Bar a user can see:
    1. all the recent activity going on in Studio - who's working on what issue, who committed what and how long ago
      issues assigned to you
    2. what reviews you need to do
    3. recent builds
    4. favorite wiki pages
    5. unread mail in your Gmail inbox
    6. recent Google Docs
    7. any upcoming events on your Google Calendar
    8. and chat with anyone with a Google Talk or Jabber account

    All without leaving the JIRA Studio environment.

    Initial planning

    Our initial estimate for implementing this feature was, "a lot of work". I'm pretty sure we underestimated. The immediate question that jumped out at us and continued to bother us during development was, "How can we scale this?" Instant messaging is typically done with a persistent connection to the chat server. That way the server can "push" messages to clients when they're sent. That's what makes it "instant." To do the same with a browser we'd need to use some Comet techniques for maintaining a connection between the browser and server. In Java apps, this typically means a thread will be blocked waiting for something to do. It was immediately obvious that this just wouldn't scale very well. For a Studio instance with 30-50 users, we could expect at least that many threads to be tied up all the time.

    How do we scale?

    So we started looking at how we could do non-blocking I/O in Java apps. Fortunately, most Java app servers have some form of non-blocking, asynchronous I/O capabilities these days. Unfortunately, they have different APIs for using those capabilities since Servlet 3.0 implementations aren't yet wide spread. To make matters worse, we weren't sure exactly what container we were going to wind up deploying to.

    You see, JIRA Studio runs on Virtual Machines on Contegix hardware. This is to keep all the customer data separate and secure. Each Studio instance is allocated a specific amount of memory so that Contegix can properly load balance instances for maximum utilization of their hardware. Studio, before adding the Google Apps integrations, was already starting to get closer and closer to exceeding that memory limit.

    How will it be deployed?

    At first, we had hoped to develop the Activity Bar as a plugin to one of our apps. Because of the way servlets are wrapped in our plugin system this proved to be impossible as there is no way to access any of the container-specific methods for doing asynchronous I/O. Our next thought was to deploy it as a separate webapp. We could do that simply with a minimal web server like Jetty or Grizzly. We debated whether the app would meet the limited memory footprint even with the most minimal web server we could find, since the JVM by itself would take up 40-50MB of memory. The final thought was that we would deploy the Activity Bar webapp in one of the existing containers alongside JIRA, Confluence, Crowd or Bamboo. Even that decision was destined to change.

    So, amidst all this uncertainty, which ironically couldn't be cleared up until we had something to deploy, what was a developer to do? Well, the same thing we always do. Abstract, abstract, abstract. Atmosphere was built exactly to solve this problem. By using its APIs you can run on any of the myriad of containers with asynchronous I/O support and not have to worry about the details. Even better, it integrates well with the Jersey library for building RESTful services, making it even easier to use! And to top it all off the developers are quick to patch and release bug fixes as they are found. We certainly couldn't have completed this project as quickly as we did without Atmosphere, so I want to give a big thanks to Jean-Francois for all his help.

    Early days

    And so we set out to develop the chat backend as a separate web application, to be run on an as-yet-undetermined container using Atmosphere to abstract away the details of doing asynchronous I/O. In pretty quick order we were able to get logging in to Google Talk, fetching the buddy list, message sending and receiving, and handling presence updates all working.

    We naively did this using the HTTP streaming form of Comet techniques. This worked well for a while until we started doing some more tests and added error handling. At this point two nasty problems reared their ugly heads: 1) you couldn't really do any error handling if the connection failed, 2) if the initial connection succeeded but timed out after a while, there wasn't much we could do to detect that. This was due to the fact that the connection with the browser was maintained in an iframe. When the server needs to send a message to the browser, it simply spits out a <script> tag containing a call to a JavaScript function to handle it. Well, there is really no way of determining the HTTP responses status code of an iframe. That meant that when a connection problem occurred, there would be little we could do to handle it. As for the second problem, we might have created an onload event handler such that when it was invoked it would remove the iframe and create a new one to receive notifications. The two problems, combined, however, made us realize that HTTP streaming just isn't a great solution, so we set out to implement long polling instead.

    Looking back, while HTTP streaming wasn't the best solution for us, it wasn't an entirely bad way to start. We avoided issues like storing notifications between polling requests that we otherwise would have had to deal with and we were able to get the UI development going with real live data while the migration to long polling was being done. It was also good because it made us confident that yes, this really would work and we could pull it off in the short time frame we had been given. While it wasn't the best solution, it was a good way to get started and the migration to long polling wasn't all that difficult or disruptive because we had a good foundation to work from.

    Not too surprisingly the application tabs were the easiest bits to get working. For pulling data from JIRA, Confluence, Crucible and Bamboo we just had to request feeds for the data we wanted and parse and display them. Since all JIRA Studio apps come from, we didn't have to worry about any same origin policy issues and SSO took care of our authentication needs. The Google Apps data was a bit harder to come by because we did need to worry about the same origin policy and authentication.

    As luck would have it, the other features that were being worked on as part of our integration work took care of all of that very nicely. To allow a user to see a list of Google Docs in Confluence and pick a document to attach to an issue, the integration team had developed plugins for the Atlassian applications that acted as proxies to the actual Google Data APIs. Authentication is handled using OAuth, which is setup automatically between your JIRA Studio instance and Google at the time you sign up. With those feeds available to the Activity Bar, it was a simple matter of fetching and parsing them to display your Google Docs, upcoming Google Calendar events and unread messages in your inbox.

    By Richard Wallace, Atlassian

    Now it's just a matter of rolling it out, right? Not quite. Part 2 of this series talks through a few other hurdles we had to jump over (or crash through) to get ready for launch.

    [Gd] [Search Loader All][Release] ClientLocation fixed, etc.

    | More

    Google AJAX API Alerts: [Search Loader All][Release] ClientLocation fixed, etc.

  • Tab characters are escaped in JSON
  • ClientLocations restored for affected IP addresses
  • New Static Map URL in the Local Search API
  • URL:

    Tuesday, March 23, 2010

    [Gd] Stable Update: Fix Extension Install Issue

    | More

    Google Chrome Releases: Stable Update: Fix Extension Install Issue

    Google Chrome has been released to the Windows Stable channel.

    This release fixes an issue with some extensions not installing from the Google Chrome extensions gallery (issue 38220).

    --Mark Larson, Google Chrome Team 

    [Gd] Google Sites API v1.2: Page Templates and Web Address Mappings

    | More

    Google Apps Developer Blog: Google Sites API v1.2: Page Templates and Web Address Mappings

    Today we’re releasing Google Sites API, version 1.2, which includes two top requested new features:

    Web address mappings

    Web address mappings are now programmatically accessible in the API using a new parameter on the site feed: with-mappings=true. If you’re not familar with this feature in Google Sites, web address mappings enable users to point their own domains to a Google Site. For example, you can map the address to They’re a great way to fully customize a site.

    See our help center article for more information on web address mappings.

    Page templates

    A few months ago we launched site templates in the API, but there was no way to use page templates or access them programmatically. With the new page templates API, you can create templates as well as instantiate new pages from existing templates.

    As an example usage, this Java snippet creates a new filecabinetpage from an existing template filecabinet:
    FileCabinetPageEntry templateInstanceEntry = new FileCabinetPageEntry();
    new PlainTextConstruct("File cabinet template instance"));
    templateInstanceEntry.addLink(new Link(SitesLink.Rel.TEMPLATE,

    String feedUrl = "";
    FileCabinetPageEntry fileCabFromTemplate = client.insert(
    new URL(feedUrl), templateInstanceEntry);

    Check out the documentation, updated Java guide, and changelog for further information.

    Bug fixes in this release: 1903, 1762

    Posted by Eric Bidelman , Google Sites API Team

    [Gd] Alert: 30 days before major v13 sunset

    | More

    AdWords API Blog: Alert: 30 days before major v13 sunset

    Attention AdWords API developers: you now have just 30 days to migrate your application to the new AdWords API. On April 22, most v13 services will be sunset. We announced version v200909 on October 22, 2009 and told you that in six months we would sunset most v13 services. If you have not begun migrating your application to v200909, it’s very important that you start right away.

    Be sure to follow us on Twitter for the latest news, tips, and tricks about the AdWords API and please post your migration questions to the Developer Forum.

    – Jason Shafton, Product Marketing Manager

    Monday, March 22, 2010

    [Gd] Partial Responses and Updates with the YouTube API

    | More

    YouTube API Blog: Partial Responses and Updates with the YouTube API

    We wanted to share some big news that was just announced on the Google Code blog: the YouTube API now supports partial responses and partial update requests. Both these features allow you to drastically cut down on the amount of data you send and receive via the API, which means simpler, faster API operations and happier users.

    The announcement post on the Google Code blog goes into much more detail, so take a look at that first. When you’re ready to start writing code, check out the partial response and partial update sections of the YouTube API Developer’s Guide.

    -Jeff Posnick, YouTube API Team
    YouTube is hiring! ~

    [Gd] Resumable Upload for the Google Data APIs

    | More

    Google Apps Developer Blog: Resumable Upload for the Google Data APIs

    If you’re backing up local files to Google Docs using the Documents List API, there’s nothing more frustrating than having the upload fail moments before it completes. Unfortunately, current web protocols provide no guidance for reliably restarting failed uploads using HTTP. Because of this limitation, file uploads at Google and other sites have traditionally been limited to moderate sizes (e.g. 100 MB). For API services like the Google Documents List API and the YouTube API (both of which support large file uploads), this presents a major hurdle.

    So today we’re rolling out a feature across the Google Data APIs that supports resumable POST/PUT HTTP requests in HTTP/1.0. The protocol was modeled after the ResumableHttpRequestsProposal suggested by Google Gears team. The protocol itself is straightforward. First your client makes an initial POST request to an API endpoint to obtain a unique upload URI:
    POST /feeds/upload/create-session/default/private/full?convert=false HTTP/1.1
    GData-Version: 3.0
    Authorization: <your authorization header here>
    Content-Length: 292
    Content-Type: application/atom+xml
    X-Upload-Content-Type: application/msword
    X-Upload-Content-Length: 7654321

    <?xml version='1.0' encoding='UTF-8'?>
    <entry xmlns=""
    <category scheme=""
    <docs:writersCanInvite value="false"/>

    Next, the file is sent in chunks to the server using the Content-Range header. This single request sends the first 100000 bytes of 1234567 byte PDF file:
    PUT <unique_upload_uri> HTTP/1.1
    Content-Length: 100000
    Content-Type: application/pdf
    Content-Range: bytes 0-99999/1234567

    <bytes 0-99999>

    For now, the resumable upload feature is only available in the DocList and YouTube APIs. The Java, Python, Objective-C, and .NET libraries have been updated to support the resumable functionality and documentation and client library samples can be found on

    Posted by Eric Bidelman, Google Apps API Team

    [Gd] Making APIs Faster: Introducing Partial Response and Partial Update

    | More

    Google Code Blog: Making APIs Faster: Introducing Partial Response and Partial Update

    At Google, we strive to make the web faster. Today, we’re proud to take our first big step in making APIs faster by introducing two experimental features in the Google Data Protocol, partial response and partial update. Together, partial response and partial update can drastically reduce the network, memory, and CPU resources needed to work with Google APIs.

    It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.

    With the addition of partial response, however, you can now use the fields query parameter to request only relevant information -- in this case, event titles and times. Constructing such a request using the fields query parameter is simple:


    By including the entry argument and specifying title and gd:when, this request ensures that the partial response contains only the title and time for each event, along with a small amount of wrapping metadata.

    But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP PATCH verb to send the modified data back to the server. The server then intelligently interprets your PATCH, updating only the fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data remains server-side and untouched.

    Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.

    As of today, partial response and partial update are supported in four Google APIs:
    ... and we’re planning on adding support for most of the APIs that are built on the Google Data Protocol soon. Stay tuned for more information, and if you can’t wait, feel free to lobby for partial update and partial response in your favorite API’s public support group. And for those of you who’ll be at Google I/O this year, be sure to check out the Google API sessions that are in store.

    Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!

    By Kyle Marvin and Zach Maier, Google Data Protocol Team

    [Gd] [Libraries][Update] jQueryUI 1.8.0

    | More

    Google AJAX API Alerts: [Libraries][Update] jQueryUI 1.8.0

    jQueryUI was updated to 1.8.0.