Today we are releasing version 1.2.5 of the App Engine SDK for both Python and Java, our first simultaneous release across both runtimes. We're excited about the great new functionality in this release ... including XMPP!
XMPP (or Jabber as it is sometimes known) is an open standard for communicating in real-time (instant messaging). One of the most popular API requests in the App Engine issue tracker has been support for XMPP, so today we are excited to mark that issue closed with the release of our new XMPP API for both Python and Java SDKs!
Like the other APIs that App Engine provides for developers, XMPP is built on the same powerful infrastructure that serves other Google products. In this case, we take advantage of the servers that run Google Talk. This new API allows your app to exchange messages with users on any XMPP-based network, including (but not limited to!) Google Talk. If you're currently participating in the Google Wave developer preview, you can also use the XMPP API to build bots that interact with your waves.
We've tried to make the XMPP API as simple as possible to incorporate into your existing Python or Java applications. We use the same webhook pattern that Cron and Task Queue already use: you send outgoing messages with an API call; you receive incoming messages as an HTTP POST. You can read more about the features the XMPP API in our documentation (Python, Java).
We're very proud of our first XMPP release, but there's still more work to do. In the future we hope to provide even more functionality to apps, such as user status (presence) and info on new subscriptions. If you have particular requests or feedback, please let us know.
Python developers have been processing tasks offline using App Engine Task Queues since mid-June, but until now the feature was not available in the App Engine for Java SDK. The 1.2.5 SDK now includes support for creating Tasks and Queues in our Java runtime.
If you're familiar with the Python Task Queue API, the Java version will look very familiar. We use the same webhooks pattern as with Cron (and now XMPP). The API provides a simple pattern for creating tasks, assigning them a payload and a worker, and inserting them into queues for scheduling and processing. There's lots of potential with the Task Queue API, so make sure to check out the Java Task Queue Documentation for more details.
With the 1.2.5 release, we are increasing the daily quota for Task Queue insertions to 100K for billing-enabled apps. Ultimately, we will raise the quota for both free and billing-enabled apps, but we hope this intermediate step opens up new scenarios for our developers using Task Queues.
Last but not least, we're very excited that 1.2.5 for Python now includes a Windows-based version of a useful tool that Mac OS X users have been enjoying for sometime: The Google App Engine Launcher!
This tool simplifies the process of creating new Python projects, testing them locally, and uploading them to the App Engine servers. In addition, we're releasing the source code for both Mac and Windows App Engine Launchers as open source projects. Watch this space for more details on where you can find the source, and how Linux developers can use the Launcher as well.
1.2.5 also includes the usual set of bug fixes, tweaks, and API polish. For a more detailed look at all the things that have changed this release, take a look at our release notes and, as always, let us know what you think!
When we released version 1.2.4 of the SDK earlier this month, a couple of new features were released that didn't quite make it into the release notes. We think they're really cool features, so we wanted to take the time to highlight them.
The first feature is that when logged into your app as an administrator, App Engine will include a couple of extra headers in all the HTTP responses it sends you. As an example, here's what I see in Firefox's Live HTTP headers plugin when I load my blog:X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236X-AppEngine-Estimated-CPM-US-Dollars: $0.012320
X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236X-AppEngine-Estimated-CPM-US-Dollars: $0.012320
The first header tells me that it took 293 milliseconds to generate the page, and 500 CPU milliseconds were consumed, of which 236 milliseconds were spent doing API calls - such as accessing memcache or the datastore. The second header tells me that App Engine estimates that serving 1000 requests like this one would cost about $0.01 if I was above my free quota - not bad!
You can view these headers using plugins such as Firefox's Live HTTP Headers or Firebug. Note that only logged in administrators see these figures - ordinary users, and users who aren't logged in, won't see them at all.
The second new feature is that we've enabled 'wildcard' domains for App Engine apps serving off appspot.com. What this means is that you can now create multiple subdomains for your App Engine app, and have them all served by the same application. Thus, your users can access 'myapp.appspot.com', or 'developer.myapp.appspot.com', or 'news.myapp.appspot.com', with your app deciding how to handle each request. No setup is required to use the wildcard domains - simply configure your app to serve up requests to these subdomains however you wish. You can detect which domain a user requested by looking at the 'Host' header in the incoming request - for example, in Python's webapp framework you can access this with self.request.headers['Host'].
Every month or so, we compile a list of interesting things in the community related to App Engine. Here are some recent projects and resources that you might find interesting:
Ubisoft has released a fun game for Facebook called TickTock which challenges you to guess which of your friends have posted particular status updates. From the application page "TickTock is a Facebook trivia game that tests your knowledge of your friends. Use that knowledge to create playful devices to challenge others. Unlock items and create bigger challenges. Post them on your people's Facebook Walls, and see who knows their friends best!"
TickTock uses App Engine to serve the game content and store game information. We're excited to see this as a great example of a growing number of games which are using App Engine behind the scenes. Sign on to Facebook and give it a try.
Written by a group of engineers at VendAsta, asynctools is a rather nifty toolkit that allows you to execute datastore queries in parallel in the Python runtime. The interface is slightly more involved than using standard queries, but the ability to execute multiple queries in parallel can substantially reduce the render time for a page where you need to execute multiple independent queries.
Jason Collins has written a detailed article about how and why they wrote asynctools, which can be found here.
DryDrop is a new tool that lets you host your static site on Google App Engine and update it by pushing to GitHub. Thanks to GitHub post-receive hooks your App Engine site can be updated automatically when you push new content.
We have a new screencast up in the Developer's Channel on YouTube, this one covers Installing Google App Engine applications into Google Apps.
For more open source projects built on top of Google App Engine, see the Open Source Projects wiki page, and feel free to add your own open source projects to that page if you want to see them featured in an upcoming community update post.
Posted by Jeff Scudder, Nick Johnson, and Jason Cooper, App Engine Team
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
We're psyched to release version 1.2.4 of the App Engine SDK for Python. Some highlights of what you'll find in this release:
For full details, please see the SdkReleaseNotes wiki page.
Downloads for Windows, Mac, and Linux are available on the Downloads page. This SDK update was for the Python runtime, so please post your feedback in the Python runtime discussion group.
We'd also like to draw your attention to two new articles from App Engine team members:
The App Engine datastore API comes with a wide range of Property classes you can use to represent properties on your datastore models. Occasionally, though, you'd like to do something that the designers didn't think of. Fortunately, it's really easy to extend the Datastore API with custom Property classes. In this blog post, we'll demonstrate how to write your own Property class to store Python's decimal data type.
The Property interface is documented here, but there are two essential methods our DecimalProperty must override: get_value_for_datastore, and make_value_from_datastore. We also need to declare one field, data_type, that specifies the data type our property class will contain. Let's start with a straightforward implementation:
class DecimalProperty(db.Property): data_type = decimal.Decimal def get_value_for_datastore(self, model_instance): return str(super(DecimalProperty, self).get_value_for_datastore(model_instance)) def make_value_from_datastore(self, value): return decimal.Decimal(value)
Note that in the case of get_value_for_datastore, we used super to call the parent class implementation, which handles the details of actually storing and retrieving the data stored in the model. We then simply convert the value to a string for storage in the datastore. In make_value_from_datastore, we reconstruct a Decimal object from the stored string.
That's all that's required for a basic property class! There is something missing from our example, though: We don't perform any validation to make sure that the user actually passed in a Decimal object. To do that, we override the validate method:
def validate(self, value): value = super(DecimalProperty, self).validate(value) if value is None or isinstance(value, decimal.Decimal): return value elif isinstance(value, basestring): return decimal.Decimal(value) raise db.BadValueError("Property %s must be a Decimal or string." % self.name)
Again we start by calling the parent class's implementation, which performs some basic validity checks. Then we check if the value is a Decimal - in which case we return it - or a string, in which case we convert it to a decimal and return it. If the value is invalid, we raise a BadValueError.
Using our property class is as simple as using any other one:
class MyModel(db.Model): a_decimal = DecimalProperty()model = MyModel()model.a_decimal = decimal.Decimal("123.45")model.put()
For a more in depth treatment of writing your own property class, see the article by Rafe Kaplan, Extending Model Properties.
The latest release of Python SDK 1.2.3, which introduced the Task Queue API and integrated support for Django 1.0, may have received a lot of attention, but there have been a number of other notable launches and events since our last update. Several of these are summarized below.
On June 24th, Google Apps and Virgin America invited people from around the world to participate in a one-day online scavenger hunt called Day in the Cloud. Competitors were each given one hour to solve various puzzles and find answers to a host of trivia questions, and prizes were awarded to the top five scorers. The site was hosted on App Engine's scalable infrastructure. For more information on the challenge, including photos and videos of participants competing mid-flight, check out the official Day in the Cloud Lounge.
App Engine enables you to deploy and run your Python- and Java-based web applications on Google's highly scalable infrastructure. There are a number of ways to optimize the performance of an application running on App Engine, some obvious and others more subtle. With this in mind, we recently released a series of articles promoting tips and tricks that you can use to make best use of resources like memcache and prevent potential issues such as datastore contention.
We also updated the articles listing since we recognized that the growing number of articles added since April 2008 (over 35 by last count) made it difficult to find content on a specific topic. The new listing allows you to filter the list of articles based on a particular tag or label, so you can easily find all articles related to the datastore, for example.
As always, we are interested in your comments, thoughts and suggestions for new articles, so please feel free to share.
Google Earth API support engineer Roman Nurrik recently open sourced his GeoModel project. GeoModel uses geohash-like objects called 'geocells' to provide a generalized solution for indexing and querying geospatial data in App Engine. GeoModel is optimized for the basic real estate finder/store locator use case, but can be adapted for use with large datasets.
Using GeoModel, developers can instantly geo-contextualize datastore models by simply inherting from the GeoModel class. Currently, entities can be associated with a single geographic point and subsequently indexed and filtered by either conformance to a bounding box or by proximity (nearest-n) to a search center point.
Posted by Jason Cooper, App Engine Team
Use promo code NEXT1720 to save $300 off general admission
Follow