India’s first ever individual Gold Medal

World champion Abhinav Bindra wins India’s first ever individual gold at the Olympic Games by winning the gold medal at the men’s 10m air rifle event in Beijing. The bespectacled shooter managed a series of 100, 99, 100, 98, 100 and 99. Let’s all wish him on creating history and for bringing pride to India

A file-photo of Abhinav Bindra

Beijing, Aug 11 (IANS) The Indian national anthem was played at an Olympics venue after 28 years as shooter Abhinav Bindra made history here Monday, winning the country its first individual Olympic gold medal. The last time India had won a gold medal at the Olympics was the hockey gold at 1980 Olympics in Moscow.

The 25-year-old bespectacled shooter showed nerves of steel as he scored 104.5 in the final to add to his 596 in the qualifier for a total of 700.5 points that gave him the coveted gold.

That composure gave way to a couple of blinks as he stood at attention while “Jana Gana Mana” was played and the Indian tricolour went up at the shooting range hall of the Beijing Olympics.

Bindra, the 2006 World Champion, claimed the gold ahead of China’s Qinan Zhu, who won the silver with a tally of 699.7 points (597 in the qualifier + 102.7 in the final). Finnish shooter Henri Hakkinen got the bronze with 699.4 points ( 598+100.4).

“It is a proud moment for me and a victoy for India. Olympic sports is not given priority in India. I hope now the focus will be on Olympic sports in the country,” Bindra told reporters at the Shooting Range Hall moments after the medal presentation ceremony.

Bindra finished fourth in the qualification round and his compatriot Gagan Narang narrowly missed the final as he finished ninth. After the qualifying round, Narang was tied with five shooters but failed to make into the top eight on the basis of back count.

To Lose Your “Cuil” 20 Seconds After Launch

The hype cycle now lasts less than a day. Take yesterday’s over-hyped launch of stealth search startup Cuil, which was quickly followed by a backlash when everyone realized that it was selling a bill of goods. This was entirely the company’s own fault. It pre-briefed every blogger and tech journalist on the planet, but didn’t allow anyone to actually test the search engine before the launch.

The company’s founders have a good pedigree, and have developed a unique way to index the Web cheaply and at massive scale. But creating a big index is only half the battle. A good search engine has to bring back the best results from that haystack as well, here Cuil falls short.

The story quickly turned from Google-killer to Google’s lunch (make that an amuse bouche). The results Cuil returns aren’t particularly great, and sometimes completely off the mark. For instance, a search for “Cuil” doesn’t even bring up a link to itself on the first page of results.

Ex-Google engineers launched ‘Cuil’ a better search engine

Anna Patterson’s last Internet search engine was so impressive that industry leader Google Inc. bought the technology in 2004 to upgrade its own system.

She believes her latest invention is even more valuable — only this time it’s not for sale.

Patterson instead intends to upstage Google, which she quit in 2006 to develop a more comprehensive and efficient way to scour the Internet.

The end result is Cuil, pronounced “cool.” Backed by $33 million in venture capital, the search engine plans to begin processing requests for the first time Monday.

Cuil had kept a low profile while Patterson, her husband, Tom Costello, and two other former Google engineers — Russell Power and Louis Monier — searched for better ways to search.

Now, it’s boasting time.

For starters, Cuil’s search index spans 120 billion Web pages.

Patterson believes that’s at least three times the size of Google’s index, although there is no way to know for certain. Google stopped publicly quantifying its index’s breadth nearly three years ago when the catalog spanned 8.2 billion Web pages.

Cuil won’t divulge the formula it has developed to cover a wider swath of the Web with far fewer computers than Google. And Google isn’t ceding the point: Spokeswoman Katie Watson said her company still believes its index is the largest.

After getting inquiries about Cuil, Google asserted on its blog Friday that it regularly scans through 1 trillion unique Web links. But Google said it doesn’t index them all because they either point to similar content or would diminish the quality of its search results in some other way. The posting didn’t quantify the size of Google’s index.

A search index’s scope is important because information, pictures and content can’t be found unless they’re stored in a database. But Cuil believes it will outshine Google in several other ways, including its method for identifying and displaying pertinent results.

Rather than trying to mimic Google’s method of ranking the quantity and quality of links to Web sites, Patterson says Cuil’s technology drills into the actual content of a page. And Cuil’s results will be presented in a more magazine-like format instead of just a vertical stack of Web links. Cuil’s results are displayed with more photos spread horizontally across the page and include sidebars that can be clicked on to learn more about topics related to the original search request.

Finally, Cuil is hoping to attract traffic by promising not to retain information about its users’ search histories or surfing patterns — something that Google does, much to the consternation of privacy watchdogs.

Cuil is just the latest in a long line of Google challengers.

The list includes swaggering startups like Teoma (whose technology became the backbone of, Vivisimo, Snap, Mahalo and, most recently, Powerset, which was acquired by Microsoft Corp. this month.

Even after investing hundreds of millions of dollars on search, both Microsoft and Yahoo Inc. have been losing ground to Google. Through May, Google held a 62 percent share of the U.S. search market followed by Yahoo at 21 percent and Microsoft at 8.5 percent, according to comScore Inc.

Google has become so synonymous with Internet search that it may no longer matter how good Cuil or any other challenger is, said Gartner Inc. analyst Allen Weiner.

“Search has become as much about branding as anything else,” Weiner said. “I doubt (Cuil) will be keeping anyone at Google awake at night.”

Google welcomed Cuil to the fray with its usual mantra about its rivals. “Having great competitors is a huge benefit to us and everyone in the search space,” Watson said. “It makes us all work harder, and at the end of the day our users benefit from that.”

But this will be the first time that Google has battled a general-purpose search engine created by its own alumni. It probably won’t be the last time, given that Google now has nearly 20,000 employees.

Patterson joined Google in 2004 after she built and sold Recall, a search index that probed old Web sites for the Internet Archive. She and Power worked on the same team at Google.

Although he also worked for Google for a short time, Monier is best known as the former chief technology officer of AltaVista, which was considered the best search engine before Google came along in 1998. Monier also helped build the search engine on eBay’s online auction site.

The trio of former Googlers are teaming up with Patterson’s husband, Costello, who built a once-promising search engine called Xift in the late 1990s. He later joined IBM Corp., where he worked on an “analytic engine” called WebFountain.

Costello’s Irish heritage inspired Cuil’s odd name. It was derived from a character named Finn McCuill in Celtic folklore.

Patterson enjoyed her time at Google, but became disenchanted with the company’s approach to search. “Google has looked pretty much the same for 10 years now,” she said, “and I can guarantee it will look the same a year from now.”

Twitter At Scale: Will It Work?

Only two days ago the contact messaging application Twitter suffered another bout of downtime, leaving some users frustrated and others asking why the platform continues to suffer problems.

I have recently spoken to an individual who is familiar with the technical problems at Twitter as well as the challenges that lay ahead for the startup. He re-iterated his belief that the problems lay not with Blaine Cook (the former head of engineering who was shown the door), nor with Joyent NTT (their host) but with the early lack of understanding of how complex their problems would be.

The issue is that group messaging is very difficult to achieve at a grand scale. Other large sites such as WordPress and Digg are mostly dealing with known problems, such as how to serve a large number of pages or a large number of images. Twitter is unique in that it needs to parse a large number of messages and deliver them to multiple recipients, with each user having unique connections to other users.

Social networks have similar complexity issues, but they only usually need to route a message to a single user (or at the most to a defined group). Even so, social networks like Friendster struggled for years with technical and scaling issues. Twitter is specifically dealing with text messages, and in most cases with active users those messages are very frequent and go out to hundreds of contacts (or followers, as they are referred to in Twitter). Every new Twitter user and every new connection results in an exponentially greater computational requirement.

Some of the best web applications are able to efficiently solve very complex problems to produce simple results for users (Eg. Google). The success of these applications is due to the innovative efforts by developers to solve large technical challenges, where they have often had to break new ground for solutions. For Twitter to reach a similar point of reliability they too will need a very comprehensive, ground-breaking solution.

The source that I spoke to also commented on how ill-prepared the Twitter team were and are for their current and future challenges. The small team contains a handful of engineers, with only a person or two committed to infrastructure and architecture. He goes on to point out that at Digg the team for network and systems alone is bigger than the total engineering team at Twitter, and that at Digg they are lead by well-known “A-list rockstars”.

The problems at Twitter are often attributed to their use of RubyOnRails, a web development framework. Twitter is almost certainly the largest site running on Rails, so fans of the framework and its developers have been quick to deflect the criticism and point it back at the engineers at Twitter. Utilizing a framework that has never conquered large-scale territory must certainly add to the risk and work required to find a solution. As an out-of-the box framework, Rails certainly doesn’t lend itself to large-scale application development, but was a big part of the reason why Twitter could experiment and release early.

Rails has enabled Twitter to prototype quickly, to quickly launch and then to easily iterate with new features. But the old adage of “Good, Fast, Cheap – pick two” certainly applies; and Rails would do itself no harm by conceding that it isn’t a platform that can compete with Java or C when it comes to intensive tasks. Twitter is at a cross-roads as an application and Rails has served its purpose very well to date, but you are unlikely to see a computational cluster built with Ruby at Apache any time soon.

What we see at Twitter today is a very useful and popular service, but one with very complex underlying technical challenges to overcome. Twitter will require not only a new architecture approach and a big injection of the best minds they can find ($15 million can help), but will also need a little patience from users and those of us observing.

FriendFeed Launches Rooms

Activity stream aggregator FriendFeed launched a new feature called FriendFeed Rooms this afternoon, which are effectively topic-based accounts that anyone can create or join (depending on privacy settings). Users can then add links and messages to relevant content.

The main difference between Rooms and a normal FriendFeed account is the fact that multiple users can author it, and that you can’t pull third party feeds into the service.

FriendFeed usage continues to grow steadily, and has clearly gained from Twitter’s (a competitor of sorts) constant downtime. I still haven’t gone religious on it, though, as some have. That’s mostly because i don’t like having a third party service centralize all this data about me and then not let that data back out again. See my rant on the Centralized Me for more on that.

According to FriendFeed a room is like a mini FriendFeed for a particular subject or group of people. You can make a room for your family, your work team, or your knitting club. If you’d like to see what a room looks like, check out the FriendFeed News room, a public room where people share and discuss FriendFeed in the press. Everyone in your room can share stuff with each other and leave comments that only other people in your room can see. You decide whether to make your room public, where anyone can join, or private, where you have to invite or approve each member. You can even choose to view everything from your rooms in your feed, instead of just in the rooms themselves.

Google’s App Engine: Aiming At Facebook, Not Amazon

There’s no shortage of stories about Google’s newly launched App Engine, but almost all of them get it wrong — because they compare the new service to Amazon’s EC2 and S3 services (AMZN).

If the Silicon Valley echo chamber wants to make up a competitor for AppEngine, its proper correlate (by a whisker) is Facebook’s F8 platform. If you must cram this new service into a pigeon hole, think of App Engine as the Facebook Platform for the grown-up web.

Why isn’t App Engine like EC2 & S3? Constraints, constraints, constraints:

* Google is going the run-time environment route, not the scalable, “put anything you want in a box and we’ll scale it” route that EC2 provides. Case in point: We could run the BricaBox Platform on EC2 by tailoring our own environment (the LAMP stack) and booting it up on Amazon’s servers. We could not get BricaBox running on AppEngine without re-writing in Python, ditching functionality which needed outside libraries or languages, or relational databases.

*Google is not trying to provide pure utility here — they are trying to provide utility tethered to their infrastructure. While EC2’s initial investor pitch was “we have this scale and want to monetize unused portions of it,” many smart people called them out for what they were really doing: creating a new business based on the concept of utility computing, which had nothing at all to do with their core infrastructure at (i.e. they weren’t using EC2 or S3 for their needs).

*Google is clearly looking to have as many of these apps tie into existing pieces of Google’s infrastructure: everything from the authentication systems (Google Accounts only!) to code libraries (most open source or API accessible code from Google is written in Python and ready to run in their environment) is based around this infrastructure and will be based around this going forward.

So, why is App Engine more like the Facebook Platform 3.0?

* App Engine is designed for lightweight apps.

* App Engine apps are wrapped around Google’s existing userbase and communication infrastructure (Gmail), creating a more organic Social Ecosystem for Google.

* App Engine is way more interoperable with the rest of the web than Facebook apps, though still built around a proprietary stack.

* The first App Engine apps will be huge! The next ones will have just as much trouble emerging from the murky waters of the web as any other apps.

Software is Dead, Long Live the Web

After a few years of trying to fill Bill Gates’ shoes as Microsoft’s chief software architect, Ray Ozzie is starting to hit his stride. In a remarkable strategy memo to employees (embedded below), Ozzie essentially shifts Microsoft’s mission from one of creating software for the PC and stand-alone servers to creating an interconnecting mesh between devices and people. He is not abandoning Windows or Office, but he is saying that the value of Microsoft’s software will increasingly depend less on what it can do on its own than what it can do with others. It is not about software anymore so much as it is about Web-based services. Ray, welcome to the club.


Central to this strategy is our embrace of both a world of the web and a world of devices. Over the past ten years, the PC era has given way to an era in which the web is at the center of our experiences – experiences delivered not just through the browser but also through many different devices including PCs, phones, media players, game consoles, set-top boxes and televisions, cars, and more.

Guiding Principles

There are three overarching principles guiding our services strategy – principles informing the design and development of products being implemented across all parts of Microsoft, for both individuals and business.

    1. The Web is the Hub of our social mesh and our device mesh.

    The web is first and foremost a mesh of people. . . . All applications will grow to recognize and utilize the inherent group-forming aspects of their connection to the web, in ways that will become fundamental to our experiences. In scenarios ranging from productivity to media and entertainment, social mesh notions of linking, sharing, ranking and tagging will become as familiar as File, Edit and View. . . . To individuals, the concept of “My Computer” will give way to the concept of a personal mesh of devices – a means by which all of your devices are brought together, managed through the web, as a seamless whole.

    2. The Power of “Choice” as business moves to embrace the cloud.

    Most major enterprises are in the early stages of a significant infrastructural transition – from the use of dedicated and sometimes very expensive application servers, to the use of virtualization and commodity hardware to consolidate those enterprise applications on computing and storage grids constructed within their data center. . . . Driven in large part by the high-scale requirements of consumer services, the value of this utility computing model is most clearly evident in cloud-based internet services.

    Software built explicitly to provide a significant level of server/service symmetry will afford choice and flexibility in developing, operating, migrating and managing such systems in highly varied enterprise deployment environments that are distributed and federated between the enterprise data center and the internet cloud.

    3.Small Pieces Loosely Joined for developers, within the cloud and across a world of devices.

    Application design patterns at both the front- and back-end are transitioning toward being compositions and in some cases loose federations of cooperating systems, where standards and interoperability are essential. . . . At a higher level, myriad options exist for delivering applications to the user: The web browser, unique in its ubiquity; the PC, unique in how it brings together interactivity/experience, mobility and storage; the phone, unique in its extreme mobility. Developers will need to build applications that can be delivered seamlessly across a loosely coupled device mesh by utilizing a common set of tools, languages, runtimes and frameworks – a common toolset that spans from the service in the cloud to enterprise server, and from the PC to the browser to the phone.

LTE Technology may hit Market Next Year

Long-Term Evolution (LTE) is one step closer to industry-wide stability. 3GPP LTE technology (LTE is the name given to a project within the Third Generation Partnership Project) offers wireless broadband speeds with downloads around 100 Mbps and upload of 50 Mbps. Seven telecommunication companies have reached an agreement on a framework for licensing intellectual-property rights that relate to LTE. This agreement will make the transition to LTE easier because the fear of lawsuits will be reduced.

Alcatel-Lucent, Ericsson, NEC, NextWave Wireless, Nokia Siemens Networks and Sony Ericsson have agreed to an industry standard being called FRAND, which stands for Fair, Reasonable And Non-Discriminatory licensing terms. Notebook computers that use LTE will pay a combined maximum royalty in the single digits. Handsets will pay a single-digit royalty that is based on a percentage of the sales price of the device.

Ericsson Senior Vice President and CTO Hakan Eriksson said this agreement will “reassure operators of the early widespread adoption of LET technology throughout the consumer electronics industry.”

Industry giant Qualcomm has yet to sign onto the FRAND framework. Other companies like Verizon Wireless, China Mobile, Vodafone and NTT DoCoMo are working on their own versions of LTE.

The future may not be here yet but it could be by next year. Wireless high-speed access will go a long way to promoting services like high-resolution video streaming and innovative online games that can be accessed almost anywhere at any time.

Alltel Wireless and Ontela Launch PhotoCopter Service

If you have ever taken a picture with your phone and then transferred it to your PC you know that your thumbs can get tired. A ontela.giftypical phone requires 100 keystrokes to transfer 10 pictures to a PC. A recent study by Ontela found that 93% of camera phone users want to save their pictures on their home computer but only 24% actually do it. Alltel Wireless and Ontela decided to take on this problem with the PhotoCopter service.

PhotoCopter automatically transfers every camera phone picture taken to a user’s home computer and favorite web photo albums. PhotoCopter is exclusively available to Alltel customers with the Motorola V3m, V3a, V9m and ROKR models. The service alltell1.jpgcosts $2.99 a month and provides customers with unlimited picture transfer to their PC, email address and web photo albums.

“Alltel realizes that our customers are capturing amazing memories on their camera phones, but until now, they have not had an easy way to transfer them to a PC for printing or sharing,” said Craig Kirkland, director of messaging and voice products at Alltel Wireless. “PhotoCopter is a simple to use application that will allow our customers to get the most of their phone’s camera and enjoy their photos in any setting.”

”It doesn’t even feel like software,” said Dan Shapiro, CEO of Ontela. “You just take the pictures and as if by magic, they appear on your computer in your ‘My Pictures’ folder. This is the end of the ‘photo graveyard,’ where people take pictures and then leave them on the phone until they’re deleted. Instead, we’ve given a new life to these memories by saving them to the places users care about most.”

This isn’t the type of service I’m willing to pay for. Frankly, there are too many embarrassing photos of me already that I wish would just go away. But if you are a 21 Century shutterbug you might appreciate the convenience a service like PhotoCopter provides.

Google App Engine : Easy to build, easy to maintain, and easy to scale

Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.

You can serve your app using a free domain name on the domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.

App Engine costs nothing to get started. Sign up for a free account, and you can develop and publish your application for the world to see, at no charge and with no obligation. A free account can use up to 500MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month.

During the preview release of Google App Engine, only free accounts are available. In the near future, you will be able to purchase additional computing resources.

Leveraging Google App Engine, developers can:

        * Write code once and deploy. Provisioning and configuring multiple machines for web serving and data storage can be expensive and time consuming. Google App Engine makes it easier to deploy web applications by dynamically providing computing resources as they are needed. Developers write the code, and Google App Engine takes care of the rest.
        * Absorb spikes in traffic. When a web app surges in popularity, the sudden increase in traffic can be overwhelming for applications of all sizes, from startups to large companies that find themselves rearchitecting their databases and entire systems several times a year. With automatic replication and load balancing, Google App Engine makes it easier to scale from one user to one million by taking advantage of Bigtable and other components of Google’s scalable infrastructure.
        * Easily integrate with other Google services. It’s unnecessary and inefficient for developers to write components like authentication and e-mail from scratch for each new application. Developers using Google App Engine can make use of built-in components and Google’s broader library of APIs that provide plug-and-play functionality for simple but important features.

Google App Engine: The Limitations

The service is launching in beta and has a number of limitations.

First, only the first 10,000 developers to sign up for the beta will be allowed to deploy applications.

The service is completely free during the beta period, but there are ceilings on usage. Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day. We’re told this equates to about 5M pageviews/mo for the typical web app. After the beta period, those ceilings will be removed, but developers will need to pay for any overage. Google has not yet set pricing for the service.

One current limitation is a requirement that applications be written in Python, a popular scripting language for building modern web apps (Ruby and PHP are among others widely used). Google says that Python is just the first supported language, and that the entire infrastructure is designed to be language neutral. Google’s initial focus on Python makes sense because they use Python internally as their scripting language

The Application Environment

Google App Engine makes it easy to build an application that runs reliably, even under heavy load and with large amounts of data. The environment includes the following features:

    * dynamic web serving, with full support for common web technologies
    * persistent storage with queries, sorting and transactions
    * automatic scaling and load balancing
    * APIs for authenticating users and sending email using Google Accounts
    * a fully featured local development environment that simulates Google App Engine on your computer

Google App Engine applications are implemented using the Python programming language. The runtime environment includes the full Python language and most of the Python standard library.

Although Python is currently the only language supported by Google App Engine, we look forward to supporting more languages in the future.

The Sandbox

Applications run in a secure environment that provides limited access to the underlying operating system. These limitations allow App Engine to distribute web requests for the application across multiple servers, and start and stop servers to meet traffic demands. The sandbox isolates your application in its own secure, reliable environment that is independent of the hardware, operating system and physical location of the web server.

Examples of the limitations of the secure sandbox environment include:

    * An application can only access other computers on the Internet through the provided URL fetch and email services and APIs. Other computers can only connect to the application by making HTTP (or HTTPS) requests on the standard ports.
    * An application cannot write to the file system. An app can read files, but only files uploaded with the application code. The app must use the App Engine datastore for all data that persists between requests.
    * Application code only runs in response to a web request, and must return response data within a few seconds. A request handler cannot spawn a sub-process or execute code after the response has been sent.

The Python Runtime Environment

App Engine provides a runtime environment that uses the Python programming language. Other programming languages and runtime environment configurations are being considered for future releases.

The Python runtime environment uses Python version 2.5.2.

The environment includes the Python standard library. Of course, calling a library method that violates a sandbox restriction, such as attempting to open a socket or write to a file, will not succeed. For convenience, several modules in the standard library whose core features are not supported by the runtime environment have been disabled, and code that imports them will raise an error.

Application code must be written exclusively in Python. Code with extensions written in C is not supported.

The Python environment provides rich Python APIs for the datastore, Google Accounts, URL fetch and email services. App Engine also provides a simple Python web application framework called webapp to make it easy to start building applications.

For convenience, App Engine also includes the Django web application framework, version 0.96.1. Note that the App Engine datastore is not a relational database, which is required by some Django components. Some components, such as the Django template engine, work as documented, while others require a bit more effort.

You can upload other third-party libraries with your application, as long as they are implemented in pure Python and do not require any unsupported standard library modules.

For more information about the Python runtime environment, see The Python Runtime Environment.

The Datastore

App Engine provides a powerful distributed data storage service that features a query engine and transactions. Just as the distributed web server grows with your traffic, the distributed datastore grows with your data.

The App Engine datastore is not like a traditional relational database. Data objects, or "entities," have a kind and a set of properties. Queries can retrieve entities of a given kind filtered and sorted by the values of the properties. Property values can be of any of the supported property value types.

The Python API for the datastore includes a data modeling interface that can define a structure for datastore entities. A data model can indicate that a property must have a value within a given range, or provide a default value if none is given. Your application can provide as much or as little structure to the data as it needs.

The datastore uses optimistic locking for concurrency control. An update of a entity occurs in a transaction that is retried a fixed number of times if other processes are trying to update the same entity simultaneously. Your application can execute multiple datastore operations in a single transaction which either all succeed or all fail, ensuring the integrity of your data.

The datastore implements transactions across its distributed network using "entity groups." A transaction manipulates entities within a single group. Entities of the same group are stored together for efficient execution of transactions. Your application can assign entities to groups when the entities are created.

For more information about the datastore, see the Datastore API reference.

Google Accounts

App Engine includes a service API for integrating with Google Accounts. Your application can allow a user to sign in with a Google account, and access the email address and displayable name associated with the account. Using Google Accounts lets the user start using your application faster, because the user may not need to create a new account. It also saves you the effort of implementing a user account system just for your application.

If your application is running under Google Apps, it can use the same features with members of your organization and Google Apps accounts.

The Users API can also tell the application whether the current user is a registered administrator for the application. This makes it easy to implement admin-only areas of your site.

For more information about integrating with Google Accounts, see the Users API reference.

The URL Fetch and Mail Services

Applications can access resources on the Internet, such as web services or other data, using App Engine’s URL fetch service. The URL fetch service retrieves web resources using the same high-speed Google infrastructure that retrieves web pages for many other Google products.

Applications can also send email messages using App Engine’s mail service. The mail service also uses Google infrastructure to send email messages.

For more information about the URL fetch and mail services, see the URL Fetch API reference and the the Mail API reference.

Development Workflow

The App Engine software development kit (SDK) includes a web server application that emulates all of the App Engine services on your local computer. The SDK includes all of the APIs and libraries available on App Engine. The web server also simulates the secure sandbox environment, including checks for imports of disabled modules and attempts to access disallowed system resources.

The Python SDK is implemented in pure Python, and runs on any platform with Python 2.5, including Windows, Mac OS X and Linux. You can get Python for your system at the Python website. The SDK is available as a Zip file, and installers are available for Windows and Mac OS X.

You can download the SDK here.

The SDK also includes a tool to upload your application to App Engine. Once you have created your application’s code, static files and configuration files, you run the tool to upload the data. The tool prompts you for your Google account email address and password.

When you build a new major release of an application that is already running on App Engine, you can upload the new release as a new version. The old version will continue to serve users until you switch to the new version. You can test the new version on App Engine while the old version is still running.

The Administration Console is the web-based interface for managing your applications running on App Engine. You can use it to create new applications, configure domain names, change which version of your application is live, examine access and error logs, and browse an application’s datastore.

Quotas and Limits

Not only is creating an App Engine application easy, it’s free! You can create an account and publish an application that people can use right away at no charge, and with no obligation. An application on a free account can use up to 500MB of storage and up to 5 million page views a month.

During this preview period, only free accounts are available. In the near future, you will be able to purchase additional computing resources at competitive market prices. Free accounts will continue to be available after the preview period.

During this preview period, you can register up to 3 applications.

Application resource limits, or "quotas," are refreshed continuously. If your application reaches a time-based quota, such as bandwidth, the quota will begin refreshing immediately at the rate for the given limit. Fixed quotas such as storage use are only relieved when you decrease usage.

Some features impose limits unrelated to quotas to protect the stability of the system. For example, when an application is called to serve a web request, it must issue a response within a few seconds. If the application takes too long, the process is terminated and the server returns an error code to the user. The request timeout is dynamic, and may be shortened if a request handler reaches its timeout frequently to conserve resources.

Another example of a service limit is the number of results returned by a query. A query can return at most 1,000 results. Queries that would return more results only return the maximum. In this case, a request that performs such a query isn’t likely to return a request before the timeout, but the limit is in place to conserve resources on the datastore.