From the introduction:
> What Is Google App Engine?
>
> 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. 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.
http://code.google.com/appengine
It's also interesting to see that we can find django, webob and pyyaml
in their sdk (license apache 2)
--
William Dodé - http://flibuste.net
Informaticien indépendant
> On 08-04-2008, Duncan Booth wrote:
>> Google have announced a new service called 'Google App Engine' which
>> may be of interest to some of the people here (although if you want
>> to sign up you'll have to join the queue behind me):
>>
>> From the introduction:
>>
>>> What Is Google App Engine?
> ...
>
> It's also interesting to see that we can find django, webob and pyyaml
> in their sdk (license apache 2)
>
Yes, it says you can use almost any Python web framework but django is the
preferred one.
Some of the comments at
http://www.techcrunch.com/2008/04/07/google-jumps-head-first-into-web-services-with-google-app-engine/
sound kind of upset, e.g.: "Python will be a deal breaker for many…"
or "Python only. What a weird decision. Not business and community-friendly at all."
Right, but that's people for you. If you watch the announcement video
Guido specifically says that other languages will be supported and
Python is merely the first. That decision wasn't Guido's, either.
But people will always prefer complaining on the grounds of insufficient
information to keeping quiet on the basis of knowledge.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
OK, now we need a compatibility layer so you can move apps from
Google App Engine to your own servers. You don't want to be locked
into a single vendor solution, especially when they reserve the right
to start charging.
Their data store uses a subset of SQL, so it's probably possible
to write a conversion layer allowing use of MySQL.
John Nagle
It supports Django, and more importantly, WSGI, so any 'framework' you
build on top of it should transfer out. Heck, you have a stand-alone
python script that comes with the developer kit for hosting your apps
on YOUR computer that you could port to use YOUR database and be done
with it. Write your own ORM or just some decent OO code for handling
data access so the database access layer can be swapped out and you
are golden. I really doubt getting away from the Googe App Engine is
going to be too terribly difficult for any intermediate Python
programmer, assuming good up-front application design.
+1 QOTW!
I'm waiting for the rush of new users to c.l.p :-)
If it comes, then aren't regularly posted FAQ's newbie friendly?
Is their a good FAQ already around that we can regularly point newbies
to?
What else could we do to make c.l.p. of more use to the newbie whp may
also be new to usenet whilst keeping c.l.p a usefull place for all?
- Paddy.
There are several things which would make moving away from Google tricky:
The backend data store, while it has a vaguely SQLish query language is an
object database not a relational database, i.e. more like ZODB than MySQL.
It uses similar concepts to django's data api but isn't the same. It should
be possible to write something simple to replace it, but given that you
only need to migrate away from Google when your data or page hits get
large, you need to replace it with something scalable.
The data store is the *only* writeable storage your application can access,
so there isn't much scope to write applications without using it.
If you use authentication then again you are tied to Google accounts (or
Google Apps accounts). For a public application that would also block
attempts to move to another platform.
The standalone script for testing is just for testing: it dummies out user
authentication (login accepts anything), and it only accepts a single
request at a time.
Maybe create a usenet/google group for newbies? A place to ask
beginners questions. And post a sticky to c.l.p. redirecting newbies
(or experienced pythoneers with newbie questions :).
2B
Or just redirect them to the already existing list
http://mail.python.org/mailman/listinfo/tutor
What do you mean by 'post a sticky'? That sounds like a web forum thing.
> If you use authentication then again you are tied to Google accounts (or
> Google Apps accounts). For a public application that would also block
> attempts to move to another platform.
Correcting myself: according to
http://code.google.com/p/googleappengine/issues/detail?id=17 is is possible
to use OpenID, it just isn't there by default.
I have a bet with a coworker that someone will implement the api, in a
way that makes migration away from Google easy, within a month.
(actually, the bet is just that there will be a project with this
goal). The reason I mention it here, is that he had the same comments
as you regarding this. My thinking is that (if past experiences can be
used as a yardstick) the python community will see this deficiency and
work to correct it. As a result of that thinking, I am fairly certain
that this concern is not a big concern. The authentication thing,
thats a bit different.
The best would be if the google datastore backend would be available
from sqlalchemy or sqlobject. I understand that the google datastore
is not a relational database but that just means that the full power
of sqlalchemy or sqlobject would not be available for this backend
only a limited subset. I think this should be doable especially
because GQL is very similar to SQL looks like it's really a proper
subset.
No, it just means they didn't take the time to read the docs and the FAQ for
themselves. :)
> Is their a good FAQ already around that we can regularly point newbies
> to?
You mean this one: http://www.python.org/doc/faq/
j
Translation: "Not
over-engineered-top-heavy-overly-complex-job-security-inducing-Java-enterprise
friendly."
j
I noticed that too, but it does have the virtue that development is done on
one's own machine rather than keeping everying on the ISP's machines, like
one web-stite 'quick' builder I have seen.
I didn't know about that list. It would be nice to have that list
duplicated as a usenet/google group (just like c.l.p).
> What do you mean by 'post a sticky'? That sounds like a web forum thing.
It is. Using Google Groups some can post a post that stays on top. Not
sure if everybody would like that. :)
2B