Friday, October 14, 2011

[Gd] Fridaygram: we want your videos, learn math from chocolate, puzzling with wood

| More

The official Google Code blog: Fridaygram: we want your videos, learn math from chocolate, puzzling with wood

Author Photo
By Scott Knaster, Google Code Blog Editor

Last month we asked you to upload videos telling us what it’s like to be a Google developer. We really want to hear from you, so we’re reminding you again just in case you haven’t submitted your video yet. This is your chance to let us know what inspires you and what you’d like from us, so please fire up your phones and cameras, and visit our developer stories page for more info.



We hope you come up with some clever ideas for your video. Here’s something you can use for creative inspiration. Tim Chartier of Davidson College takes advantage of candy bars and chocolate chips for math instruction, starting with simple concepts that lead toward fundamental calculus. And when he’s done, there’s dessert.

After you’ve eaten your math homework, here’s a puzzle: see if you can figure out how this block of wood got a nail through it. When you think you know the answer (or you give up), watch the video to see how it was done. So there’s your potential weekend project.


Fridaygram posts are just for fun - and sometimes they tell you about cool ways to mash up calculus with chocolate. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.
URL: http://googlecode.blogspot.com/2011/10/fridaygram-we-want-your-videos-learn.html

[Gd] More Ways to Find What You’re Looking For

| More

YouTube API Blog: More Ways to Find What You’re Looking For


We’ve got some exciting additions to the list of supported search parameters for YouTube feeds that should make it easier to narrow down your search results to exactly the videos you’re looking for. Each of these search parameters has an accompanying element in a video entry’s metadata, which we’ll cover as well. Here's a quick rundown:
  • license - This parameter lets you filter search results based on whether they're Creative Commons licensed (license=cc) or use the standard YouTube license (license=youtube). The default behavior is to return videos regardless of their license in search results. The license for a given video entry is reflected in its <media:license> element.
  • hd - This one lets you request videos that have high-resolution versions available. If you specify hd (no value is needed), all the videos in your search results will be available for playback in at least 720p, and higher resolutions, like 1080p, might be available, too. If you leave the parameter out, then search results won't be filtered at all based on resolution. The <yt:hd> element corresponds to this search parameter.
  • duration - If you cater to an audience with a short attention span, then this parameter is for you. This parameter lets you filter search results based on video length. To find videos less than 4 minutes long, use duration=short. To find videos that are between 4 and 20 minutes long (inclusive), use duration=medium. Only videos that are longer than 20 minutes will be returning when requesting duration=long. The <yt:duration> element in a video entry provides a video’s exact runtime.
  • 3d - Finally, for those of you living in the future who want to find 3D content on YouTube, this aptly-named parameter is for you. Adding 3d (no value is needed) to your searches will ensure that all videos you get back are available for viewing in 3D. Videos that are available in 3D will have a <yt:threed> element in them, and that element will contain more detail about the nature of the 3D content in the given video.
Putting it all together, let’s say you want to use the API to find Creative Commons-licensed 3D YouTube videos that are available in resolutions of 720p and above and are longer than 20 minutes.The following request URL will return a feed of such videos:

https://gdata.youtube.com/feeds/api/videos?prettyprint=true&v=2&license=cc&hd&duration=long&3d

As always, if you have any questions or comments, please let us know in our developer forum.

Cheers,
—Jeff Posnick, YouTube API Team
URL: http://apiblog.youtube.com/2011/10/more-ways-to-find-what-youre-looking.html

[Gd] Heading in the right direction with WebGL

| More

Chromium Blog: Heading in the right direction with WebGL

Editor's note: The Chromium WebGL team worked closely with the Maps team to help make MapsGL a reality. We invited a member of the Maps team to talk about their experience with MapsGL in the hope that it would help inform others who are interested in deploying a large scale WebGL app.

At this point it's almost hard to remember, but when Google Maps was first released in 2005, it was one of the first web applications to demonstrate what was possible with AJAX and the web platform. This project was a challenge technically but we’d like to think that it helped to fire the imaginations of web developers around the world.

Today, the Maps team is launching a beta of a brand new experience we call MapsGL. MapsGL is one of the first large scale applications to be built on top of WebGL. MapsGL makes use of 3D rendering and hardware graphics acceleration to provide an experience that is seamless, smooth, and runs directly in the browser.

Technically, MapsGL brings significant changes to how map and image tiles are rendered on the client and server. Rather than loading pre-rendered image tiles from servers, vector data for the map is sent to the browser and rendered on the fly using WebGL. This generally means that less data needs to be sent to the browser, but also that every aspect of the map needs to be rendered on the order of ~20ms per frame in order to achieve a reasonable frame rate. Imagery transitions in Maps are also enhanced by loading 3D metadata along with image tiles, allowing Maps to provide rich 3D transitions between different levels and angles of imagery.

While developing MapsGL, we found that WebGL draws from both native and web app backgrounds. For those used to working on web applications, WebGL adds a lot of functionality, but also increases the complexity of what you need to build and test. Even though WebGL is cross platform, performance varies dramatically across graphics hardware and operating systems - and what improves performance on one may hurt performance elsewhere - so testing across a wide array of setups is critical.

We also found that performance dependent Javascript and WebGL optimizations were needed in order for MapsGL to run properly on slower hardware. For example, there are a number of users with graphics cards that can't currently run WebGL content. In these cases, we don’t give the user the ability to opt-in and they can continue with the current Maps experience. Other graphics cards have somewhat poor performance for some key operations, which we measure with a small benchmark when the user first opts-in. In these cases, MapsGL falls back on a hybrid approach where we use pre-rendered raster tiles for the background of the map and only dynamically render labels on top of these.

We hope that MapsGL makes you excited to use WebGL in your own app. WebGL enables 3D graphics and immersive experiences in the browser that were formerly impossible. As WebGL becomes more robust and graphics card drivers improve, we can't wait to see what web developers will create with it. Check out the WebGL documentation and get started!

Posted by Jennifer Maurer, Software Engineer on the MapsGL team
URL: http://blog.chromium.org/2011/10/heading-in-right-direction-with-webgl.html

[Gd] Upcoming changes to OAuth 2.0 endpoint

| More

Google Apps Developer Blog: Upcoming changes to OAuth 2.0 endpoint

Editor's note: This post by Google Senior Product Manager Justin Smith has been cross-posted from the Google Code blog because we think it'll be of great interest to Google Apps developers. -- Ryan Boyd

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on November 15, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

https://www.example.com/back?error=access_denied.

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as

https://www.example.com/back?error=access_denied. After this change, it will be returned as

https://www.example.com/back#error=access_denied.

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
  1. Redirect the browser to the Google OAuth 2.0 endpoint.
  2. The user will be shown a consent page.
  3. If the user consents, parse the authorization code from the query string of the response.
  4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.
Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:
  • Users will only see the consent screen on their first time through the sequence.
  • If the application requests offline access, only the first authorization code exchange results in a refresh token.
To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code
You can maintain the current behavior by changing the target URL to:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force
You may start including these parameters in authorization code requests today.

Questions?

If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.

Justin Smith

Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).

URL: http://googleappsdeveloper.blogspot.com/2011/10/upcoming-changes-to-oauth-20-endpoint.html

[Gd] Improving the Apps Marketplace Sign-in experience

| More

Google Apps Developer Blog: Improving the Apps Marketplace Sign-in experience

Easy access and single sign-on to applications has been a cornerstone of the Apps Marketplace since it launched. When a user clicks on an app in the Google Apps universal navigation (the “more” menu), they’re immediately signed into the app resulting in the same experience as when switching between Gmail, Calendar, and other Google apps. However, sometimes users navigate directly to the homepage of the app and want to sign in there. Handling this case while still maintaining a great user experience can be challenging.

To help, we suggest that Marketplace vendors evaluate the Google Identity Toolkit (GITKit). The toolkit drastically improves the sign-in experience for Google Apps users, as well as for users of popular free webmail services such as Gmail, Yahoo! Mail, Hotmail, and AOL Mail.

The biggest improvement in the sign-in flow is that after a user has logged into your website once, their return experience will be as simple as seeing the account (or accounts) they have used with your site and clicking the one they want to use.

For example, the user Bonnie might use the sassyapp.com app for both her main job, as well as for a small business she runs with her husband Clyde. Whenever Bonnie or Clyde need to sign in to sassyapp.com, they simply click the account they want to use.


If the user does not see their account listed, then they go through a one-time flow to add the account which sends them to the screen below. A Google Apps user can either click the Gmail button or type their email address. For users who cannot login with an identity provider, they will be asked to either enter their password or create a new account after entering their email address.



This user experience is based on an industry technique called an account chooser. In fact, Google is in the process of replacing its own login box with an account chooser and you can opt-in to start using it on Google yourself.

The Google Identity Toolkit (GITkit) can be used by any website, but is particularly useful for Apps Marketplace vendors. The toolkit is an external REST-based API built on the exact same infrastructure that Google uses to be a relying party, and includes a JavaScript widget for the same account chooser experience that you can opt-in to use on Google.

For more information, refer to the GITkit and Apps Marketplace documentation.

Eric Sachs

Eric is a Product Manager for Google Security and board member of The OpenID Foundation. He has more than 15 years of experience in the areas of user identity and security for hosted Web applications. During his five-plus years at Google, he has worked as a Product Manager for many services, including the Google Account login system, Google Apps for Your Domain, orkut.com social network, Google Health, Google Security, and Internal Systems.

URL: http://googleappsdeveloper.blogspot.com/2011/10/improving-apps-marketplace-sign-in.html

[Gd] Create and manage Custom Search Engines from within Webmaster Tools

| More

Official Google Webmaster Central Blog: Create and manage Custom Search Engines from within Webmaster Tools

Webmaster level: All

Custom Search Engines (CSEs) enable you to create Google-powered customized search experiences for your sites. You can search over one or more sites, customize the look and feel to match your site, and even make money with AdSense for Search. Now it’s even easier to get started directly from Webmaster Tools.

If you’ve never created a CSE, just click on the “Custom Search” link in the Labs section and we’ll automatically create a default CSE that searches just your site. You can do some basic configuring or immediately get the code snippet to add your new CSE to your site. You can always continue on to the full CSE control panel for more advanced settings.

Once you’ve created your CSE (or if you already had one), clicking the “Custom Search” link in Labs will allow you to manage your CSEs without leaving Webmaster Tools.

We hope these new features make it easier for you to help users search your site. If you have any questions, please post them in our Webmaster Help Forum or the Custom Search Help Forum.

Posted by Sharon Xiao, Software Engineering Intern, and Ying Huang, Software Engineer
URL: http://googlewebmastercentral.blogspot.com/2011/10/create-and-manage-custom-search-engines.html

Thursday, October 13, 2011

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 15.0.874.92 for Windows, Mac, Linux, and ChromeFrame platforms

All
  • Updated V8 -  3.5.10.17
  • Fixed crash during Print Preview (96063)
  • Fixed excessive margins in printing (92000)
  • Fixed large downloads don't show progress (94468)
  • Fixed Netflix/Silverlight error (97319)
  • Disabled acceleration for background pages (96006)
  • Restored the old bookmark menus (93674)
  • Added support for an optional "requirements" section in extension/app manifests (99241)
Windows
  • Fixed window rendering issue on focus(90386)
More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Beta channel here: http://dev.chromium.org/getting-involved/dev-channel.

If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry

Karen Grunberg
Google Chrome

URL: http://googlechromereleases.blogspot.com/2011/10/beta-channel-update_12.html

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update


The Dev channel has been updated to 16.0.904.0 for Windows, Mac, Linux, and Chrome Frame.

Windows
  • [r104051] Eliminate window frame rendering errors on activate / deactivate.
Mac
  • More polish to the avatar menu bubble
  • [r103959] Restored the old bookmark menus (Issue 93674)
Full details about what changes are in this build are available in the SVN revision log.  Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/10/dev-channel-update_10.html

Wednesday, October 12, 2011

[Gd] Manage Custom Search Engines from within Webmaster Tools

| More

Custom Search Engine: Manage Custom Search Engines from within Webmaster Tools




Many Custom Search users also regularly use Webmaster Tools. To make their lives more convenient, we’ve added a “Custom Search” feature to the Labs section of Webmaster Tools. This allows you to change your basic configuration, including the list of sites to search, and get the new code without leaving Webmaster Tools.

For users who have never created a Custom Search Engine, it helps you get started by automatically creating a default CSE that searches the current site selected in Webmaster Tools.  

We hope these new features make it easier for you to provide a great search experience for visitors to your site.  And as always, we welcome your feedback.

Posted by Sharon Xiao, Software Engineering Intern, and Ying Huang, Software Engineer


URL: http://feedproxy.google.com/~r/blogspot/Syga/~3/D8dx-ZLlFMg/manage-custom-search-engines-from.html

[Gd] Take a BITE out of Bugs and Redundant Labor

| More

Google Testing Blog: Take a BITE out of Bugs and Redundant Labor

In a time when more and more of the web is becoming streamlined, the process of filing bugs for websites remains tedious and manual. Find an issue. Switch to your bug system window. Fill out boilerplate descriptions of the problem. Switch back to the browser, take a screenshot, attach it to the issue. Type some more descriptions. The whole process is one of context switching; from the tools used to file the bug, to gather information about it, to highlight problematic areas, most of your focus as the tester is pulled away from the very application you’re trying to test.

The Browser Integrated Testing Environment, or BITE, is an open source Chrome Extension which aims to fix the manual web testing experience. To use the extension, it must be linked to a server providing information about bugs and tests in your system. BITE then provides the ability to file bugs from the context of a website, using relevant templates.


When filing a bug, BITE automatically grabs screenshots, links, and problematic UI elements and attaches them to the bug. This gives developers charged with investigating and/or fixing the bug a wealth of information to help them determine root causes and factors in the behavior.



When it comes to reproducing a bug, testers will often labor to remember and accurately record the exact steps taken. With BITE, however, every action the tester takes on the page is recorded in JavaScript, and can be played back later. This enables engineers to quickly determine if the steps of a bug repro in a specific environment, or whether a code change has resolved the issue.

Also included in BITE is a Record/Playback console to automate user actions in a manual test. Like the BITE recording experience, the RPF console will automatically author javascript that can be used to replay your actions at a later date. And BITE’s record and playback mechanism is fault tolerant; UI automation tests will fail from time to time, and when they do, it tends to be for test issues, rather than product issues. To that end, when a BITE playback fails, the tester can fix their recording in real-time, just by repeating the action on the page. There’s no need to touch code, or report a failing test; if your script can’t find a button to click on, just click on it again, and the script will be fixed! For those times when you do have to touch the code, we’ve used the Ace (http://ace.ajax.org/) as an inline editor, so you can make changes to your javascript in real-time.

Check out the BITE project page at http://code.google.com/p/bite-project. Feedback is welcome at bite-feedback@google.com. Posted by Joe Allan Muharsky from the Web Testing Technologies Team (Jason Stredwick, Julie Ralph, Po Hu and Richard Bustamante are the members of the team that delivered the product).
URL: http://googletesting.blogspot.com/2011/10/take-bite-out-of-bugs-and-redundant.html

[Gd] Enhancing the Google APIs Console, one page at a time

| More

The official Google Code blog: Enhancing the Google APIs Console, one page at a time

author photo
Ion
author photo
Chris

By Ion Constantinescu and Chris Cartland, APIs Console Team


It's been nearly one year since we launched the Google APIs Console to help you manage API usage across your sites and apps. We've had some great feedback about what you like (and don't), and are working hard every day to improve the overall experience. To this end, we want to highlight a number of recent enhancements.

Introducing v2 of the Google APIs Console Traffic Reports Page

The Google APIs Console contains a list of traffic reports that display information about how the APIs enabled per project are being used. Based on customer feedback, we've made a few enhancements:
  • We have consolidated all API traffic in a single display.
  • We now compare traffic between multiple APIs in a single project.
  • We now show demographic and usage data about your API requests.
New traffic reports page

We believe we have made the Traffic Reports page cleaner and more compact without losing any functionality. We already have a list of enhancements we want to make to the page, and we would love to hear from you to help drive our prioritization.

Demographic data is available from traffic reports

Introducing the Google APIs Console Dashboard

You told us that you want to jump into a project's page and see more of a dashboard that describes what's happening on your project. You said you want to see which services are enabled, the availability of said services, general project administration, and a quick link to how much the project costs to run.

New APIs Console Dashboard

Our new Dashboard page is the first step in delivering on this experience. We will continue to enhance the Dashboard based on your collective feedback, so please take a look and let us know what you think.

New APIs Available in the Google APIs Console

We'd also like to announce some APIs are now available in the Console:

Web Fonts Developer API: this gives access to the metadata available for all families served by Google Web Fonts. You can create dynamic apps that can query Google Web Fonts and get an accurate list of the families currently available.

Google Orkut v2 REST API: this enables you to access select Orkut features. This API works like an extension of the JSON-RPC off-site application API, although it uses a different protocol.

Google Analytics Management API v3: this provides read-only access to Google Analytics configuration data. With the Management API you can list all the Account, Web Property and Profile information for a user, retrieve a Profile ID to use with the Data Export API, determine which goals are active and access their configured names, and retrieve a user's Custom Segments to apply them to Data Export API queries.

Blogger JSON API: this allows client applications to view and update Blogger content in the form of Google Data API feeds. Your client application can use the Blogger Data API to create new blog posts, edit and delete existing blog posts, and query for blog posts that match particular criteria.

We will continue to make changes and update our systems to make your development experience as great as possible. As always, if you have any questions, comments, or concerns, please contact us.


Ion Constantinescu is a Google Software Engineer working on the Google APIs Console. He has an academic background in Artificial Intelligence in the field of web service technologies.

Chris Cartland is a former Google Associate Product Manager Intern who worked on the Google APIs Console. He is currently helping CalSol - UC Berkeley's Solar Vehicle Team that designs and builds solar cars capable of racing at highway speeds - prepare to compete in the 2011 Veolia World Solar Challenge in Australia.


Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/10/enhancing-google-apis-console-one-page.html

[Gd] Upcoming changes to OAuth 2.0 endpoint

| More

The official Google Code blog: Upcoming changes to OAuth 2.0 endpoint

Author Photo
By Justin Smith, Senior Product Manager

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on November 15, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

https://www.example.com/back?error=access_denied.

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as

https://www.example.com/back?error=access_denied. After this change, it will be returned as

https://www.example.com/back#error=access_denied.

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
  1. Redirect the browser to the Google OAuth 2.0 endpoint.
  2. The user will be shown a consent page.
  3. If the user consents, parse the authorization code from the query string of the response.
  4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.
Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:
  • Users will only see the consent screen on their first time through the sequence.
  • If the application requests offline access, only the first authorization code exchange results in a refresh token.
To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code
You can maintain the current behavior by changing the target URL to:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force
You may start including these parameters in authorization code requests today.

Questions?

If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.


Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).

Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/10/upcoming-changes-to-oauth-20-endpoint.html

[Gd] App Engine Premier Accounts and a new release

| More

The official Google Code blog: App Engine Premier Accounts and a new release


By Greg D'Alesandre, App Engine team

Cross-posted from the Google App Engine Blog

2011 has seen some exciting releases for App Engine. As the days get shorter, the weather gets colder, and all that Halloween candy starts tempting everyone in the grocery store, we’ve been hard at work on our latest action-packed release.

Premier Accounts

When choosing a platform for your most critical business applications, we recognize that uptime guarantees, easy management and paid support are often just as important as product features. So today we’re launching Google App Engine premier accounts.  For $500 per month (not including the cost to provision internet services), you’ll receive:
  • Premium support (see the 
  • Technical Support Services Guidelines for details).
  • A 99.95% uptime Service Level Agreement (see the draft agreement; the final agreement will be in the signed offline agreement).
  • The ability to create an unlimited number of apps on your premier account domain.
  • No minimum monthly fees per app. Pay only for the resources you use.
  • Monthly billing via invoice.
To sign up for a premier account, please contact our sales team at appengine_premier_requests@google.com.  

Python 2.7

PIL? NumPy? Concurrent requests? Python 2.7 has it all, and today we’re opening up Python 2.7 as an experimental release. We’ve put together a list of all the known differences between the current 2.5 runtime and the new runtime.

Overall Changes

We know that bumping up against hard limits can be frustrating, and we’ve talked all year about our continued push to lift our system limits. With this release we are raising several of these:
  • Request Duration: The frontend request deadline has been increased from 30 seconds to 60 seconds. We’ve increased the maximum URLFetch deadline to match from 10 seconds to 60 seconds.
  • File limits: We’ve increased the number of files you can upload with your application from 3,000 to 10,000 files, and the file size limit has also been increased from 10MB to 32MB.
  • API Limits: Post payloads for URLFetches are now capped at 5MB instead of 1MB.
We’re also announcing several limited preview features and trusted tester programs:
  • Cloud SQL Preview: We announced last week that we are offering a preview of SQL support in App Engine. Give it a try and let us know what you think.
  • Full-text Search: We are looking for early trusted testers for our long-anticipated Full-Text Search API. Please fill out this form if you’re interested in trying it out.
  • Conversion API: Ever wanted to convert from text to PDF in your App? Then consider signing up as a trusted tester for the Conversion API.
Datastore
  • Cross Group (XG) Transactions: For those who need transactional writes to entities in multiple entity groups (and that's everyone, right?), XG Transactions are just the thing. This feature uses two phase commit to make cross group writes atomic just like single group writes.
Platform Improvements
Of course, these are just the high level changes. This release is packed full of features and bug fixes, and as always, we welcome your feedback in the group.


Greg D'Alesandre is now the Senior Product Manager for App Engine after coming back from riding the Google Wave in Sydney. And he's obsessed with chocolate, no, seriously, obsessed.

Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/10/app-engine-premier-accounts-and-new.html

[Gd] App Engine 1.5.5 SDK Release

| More

Google App Engine Blog: App Engine 1.5.5 SDK Release


2011 has seen some exciting releases for App Engine. As the days get shorter, the weather gets colder, and all that Halloween candy starts tempting everyone in the grocery store, we’ve been hard at work on our latest action packed release.






Premier Accounts


When choosing a platform for your most critical business applications, we recognize that uptime guarantees, easy management and paid support are often just as important as product features. So today we’re launching Google App Engine premier accounts.  For $500 per month (not including the cost to provision internet services), you’ll receive:


  • Premium support (see the 

  • Technical Support Services Guidelines for details).
  • A 99.95% uptime Service Level Agreement (see the draft agreement, the final agreement will be in the signed offline agreement).

  • The ability to create an unlimited number of apps on your premier account domain.

  • No minimum monthly fees per app. Pay only for the resources you use.

  • Monthly billing via invoice.





To sign up for a premier account, please contact our sales team at appengine_premier_requests@google.com.  







Python 2.7


PIL? NumPy? Concurrent requests? Python 2.7 has it all, and today we’re opening up Python 2.7 as an experimental release. We’ve put together a list of all the known differences between the current 2.5 runtime and the new runtime.







Overall Changes


We know that bumping up against hard limits can be frustrating, and we’ve talked all year about our continued push to lift our system limits. With this release we are raising several of these:


  • Request Duration: The frontend request deadline has been increased from 30 seconds to 60 seconds. We’ve increased the maximum URLFetch deadline to match from 10 seconds to 60 seconds.

  • File limits: We’ve increased the number of files you can upload with your application from 3,000 to 10,000 files, and the file size limit has also been increased from 10MB to 32MB.

  • API Limits: Post payloads for URLFetches are now capped at 5MB instead of 1MB.





We’re also announcing several limited preview features and trusted tester programs:


  • Cloud SQL Preview: We announced last week that we are offering a preview of SQL support in App Engine. Give it a try and let us know what you think.

  • Full-text Search: We are looking for early trusted testers for our long anticipated Full-Text Search API. Please fill out this form if you’re interested in trying it out.

  • Conversion API: Ever wanted to convert from text to PDF in your App? Then consider signing up as a trusted tester for the Conversion API.





Datastore


  • Cross Group (XG) Transactions: For those who need transactional writes to entities in multiple entity groups (and that's everyone, right?), XG Transactions are just the thing. This feature uses two phase commit to make cross group writes atomic just like single group writes.






Platform Improvements





Of course, these are just the high level changes. This release is packed full of features and bug fixes, and as always, we welcome your feedback in the group.






Posted by The App Engine Team
URL: http://googleappengine.blogspot.com/2011/10/app-engine-155-sdk-release.html

Tuesday, October 11, 2011

[Gd] [Libraries][Update] MooTools 1.4.1

| More

Google AJAX API Alerts: [Libraries][Update] MooTools 1.4.1

MooTools has been updated to 1.4.1
URL: http://ajax-api-alerts.blogspot.com/2011/10/librariesupdate-mootools-141.html

[Gd] Google Prediction API graduates from labs, adds new features

| More

The official Google Code blog: Google Prediction API graduates from labs, adds new features

Author Photo
By Zachary Goldberg, Product Manager

Since the general availability launch of the Prediction API this year at Google I/O, we have been working hard to give every developer access to machine learning in the cloud to build smarter apps. We’ve also been working on adding new features, accuracy improvements, and feedback capability to the API. Today we take another step by announcing Prediction v1.4. With the launch of this version, Prediction is graduating from Google Code Labs, reflecting Google’s commitment to the API’s development and stability. Version 1.4 also includes two new features:
  • Data Anomaly Analysis
    • One of the hardest parts of building an accurate predictive model is gathering and curating a high quality data set. With Prediction v1.4, we are providing a feature to help you identify problems with your data that we notice during the training process. This feedback makes it easier to build accurate predictive models with proper data.
  • PMML Import
    • PMML has become the de facto industry standard for transmitting predictive models and model data between systems. As of v1.4, the Google Prediction API can programmatically accept your PMML for data transformations and preprocessing.
    • The PMML spec is vast and covers many, many features. You can find more details about the specific features that the Google Prediction API supports here.



We’re looking forward to seeing what you create with these new capabilities!

Feel free to find us and ask questions about these new features on our discussion group or submit feedback via our feedback form.


Zachary Goldberg is Product Manager for the Google Prediction API. He has a strange fascination with the Higgs Boson.

Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/10/google-prediction-api-graduates-from.html

[Gd] Google Cloud Storage is out of Code Labs, with new features and lower price

| More

The official Google Code blog: Google Cloud Storage is out of Code Labs, with new features and lower price

Author Photo
By Navneet Joneja, Product Manager for Google Cloud Storage

Google Storage for Developers is now out of Code Labs, and has a new name: Google Cloud Storage. In addition, we're also happy to announce some new features, and a significant price reduction.

App Engine File API Support

When we opened the service to all this summer, many of our customers asked for an easier way to use Google Cloud Storage with their App Engine applications. In response to your feedback, you can now read and write your data via the App Engine Files API, enabling you to quickly build your content management tools, data sharing applications, web games and more using the powerful combination of App Engine and Cloud Storage. This feature is experimental and currently Python-only, but we’re working on adding Java support and additional features.

Usage Information

We’re introducing a new API that gives you access to detailed usage information (including network access and storage use data). You can use this feature to analyze your usage, integrate with your analysis systems and build your own value-added applications using Google Cloud Storage. This feature is currently experimental.

Lower Prices

We're no longer charging for upload bandwidth into the Google cloud. In addition, we’re lowering our prices across the board and introducing volume discounts for our larger users. We are committed to offering an extremely high quality of service to all our customers. As the product has evolved, we’ve found ways to offer the same great service at a lower cost, so now our prices are lower too. For example, under our new prices, a customer storing a hundred terabytes of data, reading twenty terabytes and writing ten terabytes a month would pay approximately 40% less a month. The difference is even greater for customers with higher usage. Our new prices are retroactive to the beginning of October. Please see our updated pricing here.

As always, we welcome your feedback in our discussion group. If you haven’t yet tried Google Cloud Storage, you can sign up and get started here.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/10/google-cloud-storage-is-out-of-code.html

[Gd] Service On/Off Now for All Apps

| More

Google Apps Developer Blog: Service On/Off Now for All Apps


You may have already noticed, but the controls to enable and disable individual apps in Google Apps are now all in one place on the domain Control Panel under Organization & users > Services.



Domain administrators were already able to use this tab to enable and disable the Core Google Apps suite. Now they can do the same for apps they've acquired from the Google Apps Marketplace. This replaces the old link labeled "Disable {app name}" in the Dashboard > {app name} > "App status" page.

App and Gadget Visibilty

This on/off switch controls app and gadget visibility. Users in suborganizations where a Marketplace App is ON will see that app in the universal navigation bar under "More", and will see the app’s contextual gadgets in Gmail. Users where the App is OFF will not see these links or gadgets.

Your customers still configure all apps through the Dashboard tab, but now the Control Panel Services tab unifies how they enable and disable every app.

New Scoping by Suborganization

The unified controls also share an important new scoping capability: now a domain administrator can select a suborganization and control which Marketplace Apps are visible to that organizational unit, just like the Core Google Apps suite!

In the example below, the administrator has overridden the domain settings for four Marketplace Apps to make three new tools visible to just the "Engineering" suborganization and to hide one application.


Visibility versus Authentication and Authorization

As developers, you should note that for any valid Google Apps domain user who goes directly to your website, OpenID/Single Sign On will always authenticate them if their domain has OpenID enabled. This includes users who are in suborganizations where your app is OFF. That means this visibility toggle feature is not a substitute for checking that the users accessing your app have a valid license.

Similarly, the on/off switch does not affect the OAuth scopes your app has been granted when the domain admin installed your app -- the admin only revokes those by explicitly revoking data access or by deleting your app. The control panel on/off switch is just a way for a domain administrator to control the visibility of apps and gadgets that would otherwise be site-wide.


Andy Rothfusz

Andy is a Developer Programs Engineer for Google Apps Marketplace. He has over 14 years of experience in developer programs covering a wide range of applications including 3D graphics acceleration, natural language processing, video games and video streaming.

URL: http://googleappsdeveloper.blogspot.com/2011/10/service-onoff-now-for-all-apps.html