Share your knowledge and create a knowledgebase.
Share your knowledge and create a knowledgebase.
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 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 appspot.com 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.
The Matrix may be the future of virtual reality, but researchers say the Grid is the future of collaborative problem-solving.
More than 400 scientists gathered at the Global Grid Forum this week to discuss what may be the Internet’s next evolutionary step.
Though distributed computing evokes associations with populist initiatives like SETI@home, where individuals donate their spare computing power to worthy projects, the Grid will link PCs to each other and the scientific community like never before.
IBM’s Brian Carpenter suggested “computing will become a utility just like any other utility.”
Carpenter said, “The Grid will open up … storage and transaction power in the same way that the Web opened up content.” And just as the Internet connects various public and private networks, Cisco Systems’ Bob Aiken said, “you’re going to have multiple grids, multiple sets of middleware that people are going to choose from to satisfy their applications.”
As conference moderator Walter Hoogland suggested, “The World Wide Web gave us a taste, but the Grid gives a vision of an ICT (Information and Communication Technology)-enabled world.”
Though the task of standardizing everything from system templates to the definitions of various resources is a mammoth one, the GGF can look to the early days of the Web for guidance. The Grid that organizers are building is a new kind of Internet, only this time with the creators having a better knowledge of where the bottlenecks and teething problems will be.
The general consensus at the event was that although technical issues abound, the thorniest issues will involve social and political dimensions, for example how to facilitate sharing between strangers where there is no history of trust.
Amsterdam seemed a logical choice for the first Global Grid Forum because not only is it the world’s most densely cabled city, it was also home to the Internet Engineering Task Force’s first international gathering in 1993. The IETF has served as a model for many of the GGF’s activities: protocols, policy issues, and exchanging experiences.
The Grid Forum, a U.S.-based organization combined with eGrid - the European Grid Forum, and Asian counterparts to create the Global Grid Forum (GGF) in November, 2000.
The Global Grid Forum organizers said grid communities in the United States and Europe will now run in synch.
The Grid evolved from the early desire to connect supercomputers into “metacomputers” that could be remotely controlled. The word “grid” was borrowed from the electricity grid, to imply that any compatible device could be plugged in anywhere on the Grid and be guaranteed a certain level of resources, regardless of where those resources might come from.
Scientific communities at the conference discussed what the compatibility standards should be, and how extensive the protocols need to be.
As the number of connected devices runs from the thousands into the millions, the policy issues become exponentially more complex. So far, only draft consensus has been reached on most topics, but participants say these are the early days.
As with the Web, the initial impetus for a grid came from the scientific community, specifically high-energy physics, which needed extra resources to manage and analyze the huge amounts of data being collected.
The most nettlesome issues for industry are security and accounting. But unlike the Web, which had security measures tacked on as an afterthought, the Grid is being designed from the ground up as a secure system.
Conference participants debated what types of services (known in distributed computing circles as resource units) provided through the Grid will be charged for. And how will the administrative authority be centralized?
Corporations have been slow to cotton to this new technology’s potential, but the suits are in evidence at this year’s Grid event. As GGF chairman Charlie Catlett noted, “This is the first time I’ve seen this many ties at a Grid forum.”
In addition to IBM, firms such as Boeing, Philips and Unilever are already taking baby steps toward the Grid.
Though commercial needs tend to be more transaction-focused than those of scientific pursuits, most of the technical requirements are common. Furthermore, both science and industry participants say they require a level of reliability that’s not offered by current peer-to-peer initiatives: Downloading from Napster, for example, can take seconds or minutes, or might not work at all.
Garnering commercial interest is critical to the Grid’s future. Cisco’s Aiken explained that “if grids are really going to take off and become the major impetus for the next level of evolution in the Internet, we have to have something that allows (them) to easily transfer to industry.”
Other potential Grid components include creating a virtual observatory, and doctors performing simulations of blood flows. While some of these applications have existed for years, the Grid will make them routine rather than exceptional.
The California Institute of Technology’s Paul Messina said that by sharing computing resources, “you get more science from the same investment.”
Ian Foster of the University of Chicago said that Web precursor Arpanet was initially intended to be a distributed computing network that would share CPU-intensive tasks but instead wound up giving birth to e-mail and FTP.
The Grid may give birth to a global file-swapping network or a members-only citadel for moneyed institutions. But just as no one ten years ago would have conceived of Napster — not to mention AmIHotOrNot.com — the future of the Grid is unknown.
An associated DataGrid conference continues until Friday, focusing on a project in which resources from Pan-European research institutions will analyze data generated by a new particle collider being built at Swiss particle-physics lab CERN.
Microsoft’s Surface computer will make its commercial debut April 17 in AT&T stores in New York City, Atlanta, San Antonio and San Francisco.
Microsoft first unveiled the Surface back in May 2007; the coffee-table like computer allows touch screen interaction with various surfaces, can recognize objects places on it and even interact with things like mobile phones.
AT&T said it planned to use the Surface to allow customers “to learn about the growing universe of mobile applications and devices.”
I had the opportunity to have a quick play with a Surface earlier this year and it’s one of the cooler things to come out of Redmond in the last 12 months, but I can’t help but wonder: isn’t putting a Surface in an AT&T store like driving an Aston Martin into a Ghetto? To be fair, interacting with a Surface at an AT&T store will be better than trying to interact with AT&T staff; not only will it be quicker (even if you queue for an hour to use it), it will actually be more polite and be able to explain the product its offering competently.
Amazon has launched Amazon TextBuyIt, a service that allows Amazon customers to purchase items via mobile phone text message.
To use the service, customers text the name of a product, its description, or its UPC or ISBN number to Amazon (262966). If Amazon stocks the item, the user will get the first two results sent to them. To purchase am item, users reply with 1 or 2 and are prompted for their email address and zip code. The service then calls the user and completes the checkout process using an automated voice system. Like regular Amazon orders, users can later track the item from Amazon.com.
The service is free to use, however items that are available as “Deal of the Day” or have a “Gold Box Discount” will not be discounted when purchased through Amazon TextBuyIt.
The obvious application for the service is price comparisons from within a physical store; customers in Borders for example could SMS a book title to see whether Amazon stocks it for less. Expect to see people texting Amazon from a store near you in the coming months.
