Prerelease SDK 1.4.0 is out!

[Ikai Lan (Google)]

Hey everyone,

I just wanted to let everyone know that prerelease SDK 1.4.0 is out! Get it from the Google Code project:

http://code.google.com/p/googleappengine/downloads/list

We're still working on the docs and will have them ready for the final release, so if there are any questions about how to use the new features, feel free to ask on this thread and I'll do my best to clarify them. The release notes are below. This is an EXCITING release:

Python

------------

- The Always On feature allows applications to pay and keep 3 instances of their

  application always running, which can significantly reduce application

  latency.

- Developers can now enable Warmup Requests. By specifying  a handler in an

  app's app.yaml, App Engine will attempt to to send a Warmup Request to

  initialize new instances before a user interacts with it. This can reduce the

  latency an end-user sees for initializing your application.

- The Channel API is now available for all users.

- Task Queue has been officially released, and is no longer an experimental

  feature. The API import paths that use 'labs' have been deprecated. Task queue

  storage will count towards an application's overall storage quota, and will

  thus be charged for.

- The deadline for Task Queue and Cron requests has been raised to 10 minutes.

  Datastore and API deadlines within those requests remain unchanged.

- For the Task Queue, developers can specify task retry_parameters in their

  queue.yaml.

- Metadata Queries on the datastore for datastore kinds, namespaces, and entity

  properties are available.

- URLFetch allowed response size has been increased, up to 32 MB. Request size

  is still limited to 1 MB.

- The Admin Console Blacklist page lists the top blacklist rejected visitors.

- The automatic image thumbnailing service supports arbitrary crop sizes up to

  1600px.

- Overall average instance latency in the Admin Console is now a weighted

  average over QPS per instance.

- The developer who uploaded an app version can download that version's code

  using the appcfg.py download_app command. This feature can be disabled on

  a per application basis in the admin console, under the 'Permissions' tab.

  Once disabled, code download for the application CANNOT be re-enabled.

- Fixed an issue where custom Admin Console pages did not work for Google

  Apps for your Domain users.

- Allow Django initialization to be moved to appengine_config.py to avoid

  Django version conflicts when mixing webapp.template with pure Django.

    http://code.google.com/p/googleappengine/issues/detail?id=1758

- Fixed an issue in the dev_appserver where get_serving_url did not work

  for transparent, cropped PNGs:

    http://code.google.com/p/googleappengine/issues/detail?id=3887

- Fixed an issue with the DatastoreFileStub.

    http://code.google.com/p/googleappengine/issues/detail?id=3895

Java

---------

- The Always On feature allows applications to pay and keep 3 instances of their

  application always running, which can significantly reduce application

  latency.

- Developers can now enable Warmup Requests. By specifying  a handler in an

  app's appengine-web.xml, App Engine will attempt to to send a Warmup Request

  to initialize new instances before a user interacts with it. This can reduce

  the latency an end-user sees for initializing your application.

- The Channel API is now available for all users.

- Task Queue has been officially released, and is no longer an experimental

  feature. The API import paths that use 'labs' have been deprecated. Task queue

  storage will count towards an application's overall storage quota, and will

  thus be charged for.

- The deadline for Task Queue and Cron requests has been raised to 10 minutes.

  Datastore and API deadlines within those requests remain unchanged.

- For the Task Queue, developers can specify task retry-parameters in their

  queue.xml.

- Metadata Queries on the datastore for datastore kinds, namespaces, and entity

  properties are available.

- URL Fetch allowed response size has been increased, up to 32 MB. Request size

  is still limited to 1 MB.

- The Admin Console Blacklist page lists the top blacklist rejected visitors.

- The automatic image thumbnailing service supports arbitrary crop sizes up to

  1600px.

- Overall average instance latency in the Admin Console is now a weighted

  average over QPS per instance.

- Added a low-level AysncDatastoreService for making calls to the datastore

  asynchronously.

- Added a getBodyAsBytes() method to QueueStateInfo.TaskStateInfo, this returns

  the body of the task state as a pure byte-string.

- The whitelist has been updated to include all classes from javax.xml.soap.

- Fixed an issue sending email to multiple recipients.

    http://code.google.com/p/googleappengine/issues/detail?id=1623

As usual, we value your feedback, so don't hesitate to evaluate these SDKs and let us know. Be mindful that the server-side components have not been deployed yet, so uploaded code shouldn't work.

Happy coding!

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Robert Kluin]

Huge release. Looking forward to it going live.

Nice work App Engine Team.

Robert

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

[Ross Karchner]

In Python, how do we use:

- Channel API

- Metadata Queries

--
Ross M Karchner

http://eventgrinder.com

[Felippe Bueno]

> - The developer who uploaded an app version can download that version's code
>   using the appcfg.py download_app command. This feature can be disabled on
>   a per application basis in the admin console, under the 'Permissions' tab.
>   Once disabled, code download for the application CANNOT be re-enabled.

good catch

[Sergio Lopes]

Excelent news! Specially to protect applications from cold start.
How can I configure WarmUp requests and Always On using Java?

Thanks and congratulations!

On Nov 18, 8:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

[Alexander W.]

I love App Engine, it gets better and better with every release and let's you do more and more cool stuff.

I'm really looking forward to it going live.

- Alexander

[Pims]

That’s a fantastic release. Can’t wait to have it in production.
Great job App Engine Team.

Tim

[Ikai Lan (Google)]

Always On will be a paid feature you enable in the admin console.

I'll post some light sample code for channel API and warmup requests in a bit.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Kangesh Gunaseelan]

Awesome additions.

Are you able to share the pricing terms for Always On feature now?

Thanks!

[Ikai Lan (Google)]

I can't share the pricing yet - wait for the release. 

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[oizo]

Metadata Queries - what's this?

[Ikai Lan (Google)]

For GAE/J you can reference this project:

http://code.google.com/p/dance-dance-robot/

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

On Thu, Nov 18, 2010 at 4:32 PM, Hitoshi <alto...@gmail.com> wrote:

Please cover GAE-J also.

Thanks!

Hitoshi

On Nov 18, 3:17 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

wrote:

> Always On will be a paid feature you enable in the admin console.
>
> I'll post some light sample code for channel API and warmup requests in a
> bit.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
>
>
>
>
>
>

> On Thu, Nov 18, 2010 at 3:11 PM, Sergio Lopes <slo...@gmail.com> wrote:
> > Excelent news! Specially to protect applications from cold start.
> > How can I configure WarmUp requests and Always On using Java?
>
> > Thanks and congratulations!
>

> > On Nov 18, 8:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>

[Alexandre Vivien]

Hi Ikai,

What about the OpenId SSL support? Is it part of this release ?

Regards,
Alexandre Vivien

On 18 nov, 17:27, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

[Ikai Lan (Google)]

It's not in the release notes, so I'd lean towards no, it didn't make it.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.

To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

[Chris Thoman]

Is the high performance image serving from the blobstore through getServingUrl / get_serving_url still going to be limited to 1600x1600?  I could really use 1920x1080 (which actually is fewer pixels).

[Wilson MacGyver]

what's the cost of the "always on" feature? I can't seem to find it anywhere.

Thanks,

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

--
Omnem crede diem tibi diluxisse supremum.

[Shaun Clark]

Is there an easy way to get this to work in Eclipse? Thanks!

On Nov 18, 3:17 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

wrote:
> Always On will be a paid feature you enable in the admin console.
>
> I'll post some light sample code for channel API and warmup requests in a
> bit.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
>
>
>
>
>
>
> On Thu, Nov 18, 2010 at 3:11 PM, Sergio Lopes <slo...@gmail.com> wrote:
> > Excelent news! Specially to protect applications from cold start.
> > How can I configure WarmUp requests and Always On using Java?
>
> > Thanks and congratulations!
>

> > On Nov 18, 8:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

[aaron frank]

Or is there a prerelease location for the documentation?

[gholler]

Really looking forward to this release. This will make a big
difference for my company's apps.
Thanks Googlers!

[Sergio Lopes]

Since I'm too excited to wait, I opened the new appengine-web.xsd in
1.4.0-pre to see how to configure the new features. There is a new
<warmup-requests-enabled/> tag with a boolean value. Of course I tried
it but it gives me an error:

400 Bad Request
Error when loading application configuration:
Value 'warmup' for key ??? does not match expression '^(mail|
xmpp_message|rest|startup)$'

Hey, Ikai, teach us to use the new features please! :-)

[风笑雪]

It's an amazing release, waiting for the docs.
----------
keakon

[Karl R]

always on is *huge*

that, combined with the generally improved latency of datastore
queries of late extinguishes my feelings that perhaps I had made the
wrong choice to run our website on GAE

On Nov 18, 10:41 pm, 风笑雪 <kea...@gmail.com> wrote:
> It's an amazing release, waiting for the docs.
> ----------
> keakon
>
>
>
>
>
>
>
> On Fri, Nov 19, 2010 at 9:47 AM, Sergio Lopes <slo...@gmail.com> wrote:
> > Since I'm too excited to wait, I opened the new appengine-web.xsd in
> > 1.4.0-pre to see how to configure the new features. There is a new
> > <warmup-requests-enabled/> tag with a boolean value. Of course I tried
> > it but it gives me an error:
>
> > 400 Bad Request
> > Error when loading application configuration:
> > Value 'warmup' for key ??? does not match expression '^(mail|
> > xmpp_message|rest|startup)$'
>
> > Hey, Ikai, teach us to use the new features please! :-)
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

[Geoffrey Spear]

Sergio,

The prerelease SDKs are for the development server only; the
production servers won't support the features until the actual
release. You can't deploy with the new features enabled, and should
continue to use the current SDK for deployed applications.

[George Moschovitis]

A great release!

thanks,
-g.

On Nov 19, 12:27 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> Hey everyone,
>
> I just wanted to let everyone know that prerelease SDK 1.4.0 is out! Get it
> from the Google Code project:

> ...

[Benjamin]

Really amazing.

Can't wait to see it release officially.

[Julian Namaro]

Wow a lot of work packed there, congrats App Engine team!

I'm surprised about the new 10 minutes deadline on Cron and Task
Queues. A short while back you were explaining that long-running
requests are bad for the App Engine ecosystem. Is it not the case for
Task Queues or are you just confident that the system has improved
enough to handle it now ?

10 minutes is a lot of time. If it works out well it will open the
door to a lot of new possibilities :)


On Nov 19, 7:27 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

[Droid]

Looking forward to always on feature which I will use immediately (and
pay for).
Please let me know when I can beta test or buy it.
DROID ( rodsit[at]gmail.com )

On Nov 18, 11:17 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

wrote:
> Always On will be a paid feature you enable in the admin console.
>
> I'll post some light sample code for channel API and warmup requests in a
> bit.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
>
>
>
>
>
>
> On Thu, Nov 18, 2010 at 3:11 PM, Sergio Lopes <slo...@gmail.com> wrote:
> > Excelent news! Specially to protect applications from cold start.
> > How can I configure WarmUp requests and Always On using Java?
>
> > Thanks and congratulations!
>

> > On Nov 18, 8:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

[Roberto Saccon]

Cool !

Has anybody figured out how to use the Channel Api and where to find
the JS files to do the clientside longpolling, iframe or whatever
comet stuff ?

I remember having played with the dance robot long time ago, that was
cool, but there there was a huge bloat load of Javascript (the whole
closure library) necessary to get it running. Is this still the
case ?

--
Roberto

[Andrius A]

Wow wow! Thank you!

To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

[Sahid Orentino Ferdjaoui]

Very impressive!

Thank you

--
  .
 ..:

[Brandon Thomson]

On Thu, Nov 18, 2010 at 5:27 PM, Ikai Lan (Google)

> - The deadline for Task Queue and Cron requests has been raised to 10
> minutes.

This is really great for background processing and timed tasks which
need greater than 1 minute resolution. Thank you!

[John]

Wow, this great stuff, definitely looking forward to the channel api:)

Great job App Engine team!

On Nov 18, 5:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

> - The deadline for Task Queue and Cron requests has been raised to 10
> minutes.

> - The deadline for Task Queue and Cron requests has been raised to 10
> minutes.

[Tapir]

I must say this release makes gae better than ec2!

On Nov 19, 6:27 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

[Sekhar Ravinutala]

Looks like a huge release, can't wait to check it out. Congrats and
thanks Google!

On Nov 18, 2:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

[Ikai Lan (Google)]

Hi Julian,

Long running user facing requests are bad for the ecosystem, yes. Long running background tasks, however, can be placed into a different execution pool. Fast background tasks are placed into the same execution pool as your web facing requests.

The rule of thumb here is to create different queues for tasks you know will run fast (sub-second) and queues for slow running jobs.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Ross Karchner]

What are the consequences of a task being in the fast pool or the slow pool?

[Ikai Lan (Google)]

Web requests share the fast pool, so there is a chance you can block all your web facing instances from serving web requests. Additionally, the latency is averaged when considering whether or not to autoscale your instances, so putting slow work in a fast queue would prevent App Engine from adding additional instances as needed.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Matthew Blain]

SSL support for OpenID should be live now. There was an issue which
prevented it from being released at the same time as the 1.3.8 release
but that issue has since been fixed.

--Matthew

[Zac Tolley]

Hey does this mean that we can finally deploy grails apps and not get
errors because its having to start up?

[Adam Sah]

+1 this is amazing. We're partying over here, just seeing this:
quite literally, we were just about to rewrite code around the
1MB limit, timeouts, django, and more.

thank you thank you thank you,
adam

[Ikai Lan (Google)]

Zac,

You shouldn't see errors on requests to your initial 3 instances. If your traffic grows at a semi linear pace, warmup requests will also start up instances before you need them and users should very rarely have their requests hit cold starts.

In our testing, we found that applications with extremely spiky traffic patterns (0-hundreds of QPS within seconds), while still benefitting from warmup requests, saw a higher frequency of users seeing cold starts. 

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

On Fri, Nov 19, 2010 at 11:33 AM, Zac Tolley <z...@thetolleys.com> wrote:

Hey does this mean that we can finally deploy grails apps and not get
errors because its having to start up?

[Zac Tolley]

sounds good. I was feeling torn between grails and pure python. On the
one hand grails gives you so much but ont he other hand its not cloud
friendly it seems. I was on the verge of having to goto EC2 for a new
app, if this works out I wont need to :)

[Eugene D]

Fantastic release! Great work guys!!

On Nov 18, 11:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

[Nischal Shetty]

WOW! Let me say that again, WOW! This month has been totally exciting
and full of pleasant surprises. And this seems to be going towards
being one of the best release ever!

Great work guys, keep it up.

-Nischal

[Ross Karchner]

Right now, I've basically been doing as little work as possible in a single task-

Fetching an iCal file in one task and persisting it, enqueueing a task to split it into single event snippets, and then each snippet gets processed in it's own task.

With a 10-minute task queue, I could easily do all of that in one fell swoop-- in fact, I could loop through some number of feeds in a single task.

The question I'm getting at: Is there still a reason to prefer lots of quick tasks over fewer, longer running tasks?

[Jagan]

Hi

- The deadline for Task Queue and Cron requests has been raised to 10
minutes.

Do you mean that now each Task Queue and Cron request can run for 10
min, instead of the old 30 seconds limit??!

Jagan

On Nov 19, 3:27 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

[Jens Lundberg]

Hi,

I'm experience issues with the 1 Mb URL fetch limitation when I post
files with ResumableUpload against Google Docs (Resumable Upload is
using the URLfetch functionality in the lower layers). I'm a bit
confused though regarding the reqeust limit (1Mb) and response-limit
(32 Mb) in the 1.4.0 SDK. Will it mean that I will still have the 1 Mb
Issue when uploading from GAE to Google Docs, but I can download a 32
Mb file from Google Docs to GAE?

I just which that I could skip the ResumableUpload to Google Docs,
since I can't get it to work with the Python SDK.

I'm I right in the above desribed assumption, 1 Mb out from GAE and 32
Mb into GAE in a URL-fetch call? (Hope it's the other way around, but
it's probably not :)

Thank you for an exciting release... looking forward to the go-live,
any date?

Regards
/Jens

[Vanni.T]

Great work, guys!

Really afraid to see a horrible uninformed anti-GAE post now #1 on Hacker News http://www.carlosble.com/?p=719

I can't believe my eyes.

[Robert Kluin]

Some of his points are perfectly valid; there are issues that deserve
attention. I think one or two of the points are out-of-date (eg 1,000
entity limit and _soon_ the 30 second background limit!).

Of course, about 1/2 of the complaints would not have been a surprise
if they spent 5 minutes and read the introduction page. And
personally, after I did the getting started "tutorial," the first
thing I asked was "how do I use this database 'for real'," then
discovered many of the nuances -- don't really understand those
complaints. You don't buy a two door car then get pissed off because
it doesn't have four doors a month later.

[Starman]

Just to be clear, is the deadline for starting up a new instance,
including from the warmup web hook, still at 30 seconds? Or is it 10
minutes as for the tasks and cron apis? One of the issues with cold
starts was to get heavier frameworks (Spring, Grails) up before the 30
seconds deadline.

[DAndrea]

Fantastic release!

I wanted a clarification about URLFetch.
With a response size limit increased up to 32mb I also would expect a
new max deadline that seems not changed (10 seconds)
Thanks!

On Nov 18, 11:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

[Haulyn R. Jason]

Nice work App Engine Team.

[Ikai Lan (Google)]

Hey,

A couple of questions were brought up in this thread. I'll do my best to answer them:

- YES, task queues and cron jobs will now have a 10 minute limit, increased from 30 seconds. Note that you still want to favor lots of small, quick tasks when possible.

- I need to verify the behavior, but the reason you will want to prefer shorter tasks is because these are scaled along with your user facing tasks = higher task throughput. Scaling of slow tasks works differently and you will ultimately receive lower throughput for those jobs, so you'll want to reserve those queues for work where you get a lot of payoff for 10 minute tasks but don't need the 50/qps per queue throughput of fast running tasks.

- Yes, you will still have a 1mb limit upload limit.

- App Instance startup still has a 30 second limit. We've explored what it would take to change this, but it's our understanding that even the heaviest of heavy frameworks (Spring MVC) can initialize in under 30 seconds. You'll still want to favor lazy initialization when possible. Again, we need to do more exploration here. The long term solution may be to increase the initialization deadline. Right now we're unsure of what'll happen if we do this, and we're unsure of whether this will be a healthy decision for the serving infrastructure overall.

- The max deadline has not changed for URLFetch. There are lots of reasons to be optimistic, however. It's in our plans to remove limits where we can - and document the tradeoffs of doing so.

I don't have an ETA (do I ever?) for the release, but as with previous releases, the go-live date is usually in the ballpark of weeks after the prerelease SDK is posted. Just keep in mind that 1.4.0 is a HUGE undertaking, so I'd leave a little more runway for when it'll go live. As usual, testing the prerelease SDK and giving us your feedback helps us ship it faster.

Also - I saw the blog post. It's unfortunate, since the author of that post posted on the forums a few times and received a lot of help from both us and members of the community. I think it's easier to remember the negative. He sounded and still sounds like someone who knows what he is talking about, so if he couldn't find the documentation about limits, that means we can do a better job of surfacing them right after someone completes the "Guestbook" tutorial, because he's sure as heck not the only one who has/is/will be surprised by these limitations. I'll look more closely at his post and model either my own blog post or some official docs after it. I'll fiercely disagree with anyone that says App Engine is not a good platform for serious businesses or that Google doesn't invest in it. Of course we do: we launch stuff on App Engine all the time. There are small teams at Google just as there are large teams, and they come to App Engine for all the reasons you all do.

Hope this helps. Keep posting feedback. I'm seeing only 100-200 downloads of the prerelease SDKs, which you can download here:

http://code.google.com/p/googleappengine/downloads/list

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Tim Hoffman]

Instance startup is still 30 seconds.

I honestly think you need to rethink your platform stack if you can't
get you average startup
time (on a good day ;-) to less than 10 - 15sec.

Rgds

T

[Vanni.T]

Hi Ikai,

about your prerelease feedback request, generally speaking we need a more direct way to suggest you SDK patches.

According to http://code.google.com/p/googleappengine/ we have to "post the code for the patch in the issue".

But nothing can help you evaluating soon those patches because they are hidden among thousands of issues without patches.

If a submitter could add a 'patch' label to the issue maybe it would be better.

For example, I submitted two (minor) new bugs with patch/fix and obviously they have still "new" status:

http://code.google.com/p/googleappengine/issues/detail?id=4055

http://code.google.com/p/googleappengine/issues/detail?id=3919

What is the GAE team preferred and effective source code SDK feedback path? I'm really glad to give my 2 (LOC) cents to the project, I am using it for my own first business project and I like FOSS so much!

Thank you,

Vanni

[kovshenin]

> The deadline for Task Queue and Cron requests has been raised to 10 minutes.

This is great! They're still counting towards the CPU seconds limit,
right?

[Ikai Lan (Google)]

If it's just 2 lines, you can post them in the group or create an issue and let us know.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

--

[Viðar Svansson]

Thank you for a great release!

Heavy frameworks like Spring MVC can be loaded really fast if you
serialize the context into cache/datastore. Unfortunately this is not
easy to do and I don't know if SpringSource is planning on making it
easier.

A blog post like that was bound to be published sooner than later.
What we need now is a counter post ;)

Cheers,
Viðar

[Constantine Vetoshev]

Ikai,

Now that the Channels API is open to everyone, do you know when we
might see some documentation for it? Just the javadocs would do for
now.

Thanks,
CV

[sandeep Koduri]

Hello ikai,

Thanks and congrats for the great release.

Will there be an option for source code download control in app.yaml. 

according to the mail thread in pre-release of 1.3.8 we thought this will be implemented, and that would be very helpful.

the feature announced now will be a very good add-on but, by default if the config is to be on app.yaml.

Will there be any option for the creator of the app to get any versions source code.

We have some use cases relying on this option. so please make a reply about this, accordingly we can streamline the development process at our team,

Thanks

Regards
Sandeep Koduri
cricwaves.com

[Ikai Lan (Google)]

You'll be able to download code, but anyone that wants to turn it off will be able to go to their admin dashboard and push a one-way, irreversible button to disallow this feature.

Please do not depend on this feature to do source control. 

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Thomas Johansson]

Why was the decision made to make this an app-wide one time only nuke
button?

I think enabling/disabling it in app.yaml per-upload would be much
more useful.

On Nov 23, 8:30 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> You'll be able to download code, but anyone that wants to turn it off will
> be able to go to their admin dashboard and push a one-way, irreversible
> button to disallow this feature.
>
> Please do not depend on this feature to do source control.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
> On Tue, Nov 23, 2010 at 11:12 AM, Sandeep Koduri

> <sandeep.kod...@gmail.com>wrote:

> >> google-appengi...@googlegroups.com<google-appengine%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/google-appengine?hl=en.
>
> > --
> > Regards
> > Sandeep Koduri
> > cricwaves.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsu...@googlegroups.com>
> > .

[Barry Hunter]

Being a one time nuke, means its not possible to for a developer to
accidentally (or maliciously) re enable downloads :)

One of the main objections to 'download' is it makes it easier for
someone who shouldnt get their hands on the source code. Yes the fact
only the uploading developer gets it, makes it more secure, but not
totally. Being able to turn off downloads, is another serious barrier
to the 'thief'. Someone who as invested IP in their code, wants to be
able to do everything possible to protect that.

> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

[Sekhar Ravinutala]

Sorry if I missed it, but are the regular requests (not queues/cron)
still limited to 30 seconds?

On Nov 18, 2:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

[Ikai Lan (Google)]

Yes, there is still a 30 second limit on web facing requests.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Thomas Johansson]

If the guy uploading enables downloads to be malicious, he could
equally just post up the code somewhere.

That being said, I hadn't thought about the case of accidentally re-
enabling and then having the account compromised. Even still, not
being able to ever turn it back on seems short sighted. Perhaps a way
to enable it similar to how disabling an app works, so it can't be
done maliciously.

On Nov 24, 6:07 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> Being a one time nuke, means its not possible to for a developer to
> accidentally (or maliciously) re enable downloads :)
>
> One of the main objections to 'download' is it makes it easier for
> someone who shouldnt get their hands on the source code. Yes the fact
> only the uploading developer gets it, makes it more secure, but not
> totally. Being able to turn off downloads, is another serious barrier
> to the 'thief'. Someone who as invested IP in their code, wants to be
> able to do everything possible to protect that.
>

[Ikai Lan (Google)]

Trust me, we thought out all the scenarios. Here are the scenarios:

1. Just enable it in app.yaml

- completely useless from a security perspective, an attacker would just enable it, download code, upload malicious code and steal data/compromise users' data over time

2. Make it opt-in, so you can't download the code unless there's a version of app.yaml that has this enabled uploaded

So an attacker can't download previous versions, but the problem here is: who would use this feature? The type of folks that want code download are unlikely to have known about this feature prior to uploading an app version.

3. Just enable it, allow disabling in app.yaml and don't allow versions uploaded before 1.4.0 going live to be downloaded

Same problems - users that ask for this feature won't benefit.

4. One way disable button

Seems to be the best compromise for all worlds. People that don't needs this feature will just turn it off once and never, ever worry about it again. Developers that need this feature (generally seem like neophyte developers who are still learning about backups and source control) won't know to turn it off, and when they lose their code, they'll be relieved they can download their code.

In general we do NOT recommend this feature as a replacement for:

1. Backups

2. Source control

A lot of folks come to App Engine because they're learning how to program, and they're not aware of source control or have "always back up your stuff" hammered in yet. See this blog post:

http://www.7bks.com/blog/179001

I'm going to be pretty adamant about not using this feature as a replacement for source control or backups in the groups, but I'm open to hearing about other reasons developers want this feature and why a permanent opt-out button is a bad idea.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[nickmilon]

Icai, I was for an opt-in solution but IMHO One way disable button is
also OK and also it takes into account the interests of newbies.

On Nov 24, 10:51 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> On Wed, Nov 24, 2010 at 12:26 PM, Thomas Johansson <prenc...@gmail.com>wrote:
>
>
>
>
>
>
>
> > If the guy uploading enables downloads to be malicious, he could
> > equally just post up the code somewhere.
>
> > That being said, I hadn't thought about the case of accidentally re-
> > enabling and then having the account compromised. Even still, not
> > being able to ever turn it back on seems short sighted. Perhaps a way
> > to enable it similar to how disabling an app works, so it can't be
> > done maliciously.
>
> > On Nov 24, 6:07 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> > > Being a one time nuke, means its not possible to for a developer to
> > > accidentally (or maliciously) re enable downloads :)
>
> > > One of the main objections to 'download' is it makes it easier for
> > > someone who shouldnt get their hands on the source code. Yes the fact
> > > only the uploading developer gets it, makes it more secure, but not
> > > totally. Being able to turn off downloads, is another serious barrier
> > > to the 'thief'. Someone who as invested IP in their code, wants to be
> > > able to do everything possible to protect that.
>
> > > On 24 November 2010 16:25, Thomas Johansson <prenc...@gmail.com> wrote:
>
> > > > Why was the decision made to make this an app-wide one time only nuke
> > > > button?
>
> > > > I think enabling/disabling it in app.yaml per-upload would be much
> > > > more useful.
>

> > > > On Nov 23, 8:30 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

> ...
>
> read more »

[Adam Sah]

+1 - I saw this design and immediately saw the tradeoffs-- hats off.

FYI even seasoned ops people occasionally need to "prove" that what's
in prod is actually what's in dev. As a real example, consider
bugs/
changes in your push scripts (in the case of GAE, wrappers for
appcfg)

It's like root on regular systems-- in theory you never need it, in
practice
every ops team has somebody who can login and once a quarter, they
use it.

thanks!!!
adam
'graduate' of google eng, invented Gadgets

On Nov 24, 3:51 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> On Wed, Nov 24, 2010 at 12:26 PM, Thomas Johansson <prenc...@gmail.com>wrote:> If the guy uploading enables downloads to be malicious, he could

> > equally just post up the code somewhere.
>
> > That being said, I hadn't thought about the case of accidentally re-
> > enabling and then having the account compromised. Even still, not
> > being able to ever turn it back on seems short sighted. Perhaps a way
> > to enable it similar to how disabling an app works, so it can't be
> > done maliciously.
>
> > On Nov 24, 6:07 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> > > Being a one time nuke, means its not possible to for a developer to
> > > accidentally (or maliciously) re enable downloads :)
>
> > > One of the main objections to 'download' is it makes it easier for
> > > someone who shouldnt get their hands on the source code. Yes the fact
> > > only the uploading developer gets it, makes it more secure, but not
> > > totally. Being able to turn off downloads, is another serious barrier
> > > to the 'thief'. Someone who as invested IP in their code, wants to be
> > > able to do everything possible to protect that.
>
> > > On 24 November 2010 16:25, Thomas Johansson <prenc...@gmail.com> wrote:
>
> > > > Why was the decision made to make this an app-wide one time only nuke
> > > > button?
>
> > > > I think enabling/disabling it in app.yaml per-upload would be much
> > > > more useful.
>

> > > > On Nov 23, 8:30 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

> > > >> >> google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > <google-appengine%2Bunsu...@googlegroups.com<google-appengine%252Bunsub scr...@googlegroups.com>

>
> > > >> >> .
> > > >> >> For more options, visit this group at
> > > >> >>http://groups.google.com/group/google-appengine?hl=en.
>
> > > >> > --
> > > >> > Regards
> > > >> > Sandeep Koduri
> > > >> > cricwaves.com
>
> > > >> > --
> > > >> > You received this message because you are subscribed to the Google
> > Groups
> > > >> > "Google App Engine" group.
> > > >> > To post to this group, send email to
> > google-a...@googlegroups.com.
> > > >> > To unsubscribe from this group, send email to

> > > >> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > <google-appengine%2Bunsu...@googlegroups.com<google-appengine%252Bunsub scr...@googlegroups.com>

>
> > > >> > .
> > > >> > For more options, visit this group at
> > > >> >http://groups.google.com/group/google-appengine?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups "Google App Engine" group.
> > > > To post to this group, send email to google-a...@googlegroups.com
> > .

> > > > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

> > > > For more options, visit this group athttp://
> > groups.google.com/group/google-appengine?hl=en.
>
> > --

> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>

[sandeep Koduri]

Hello Ikai,

  We are not using as a source code control system, we  have a core app on a version, its duty is to aggregate and store data.

we have a team who are building modules which uses the data in the datastore. 

The core app contains some confidential info about the sources of the data, which we dont want to expose to the rest.

but we want the other versions updated by the dev can be downloadable.

What i meant to say is once i upload app with the configuration in app config as not downloadable..

even if someone tries to download the app using the configuration in app config as downloadable, he will not be able to download,

As the configuration of the app in the particular version is set as not downloadable previously at the time of upload..

so the source code is safe for the particular version.

I feel this kind of option for source code download feature will be more useful.

--
Regards
Sandeep Koduri
Atok Soft India | Cricfeeds.com
Phone: +91- 99 666 02 456
Gtalk: sandeep.koduri | Skype: sandeep.koduri

[风笑雪]

Don't worry about it, the developer can only download the source code deployed by himself.

----------
keakon

[Vishal Singh]

Excellent!

[Ikai Lan (Google)]

Adam: good use case. Now that you mention it, I remember a situation in which I've logged in remotely and diff'd deployed code vs. code that I believed was deployed. In the end (as is usually the case in these situations), I realized it was user error from a bad source code merge to a branch.

Administrators of the system *should* still be able to unlock this feature for developers in an emergency, though we may place some safeguards and processes around filing a billing issue (account verification, for instance) to get it undone to minimize the cases where this would happen.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

[Ross Karchner]

Ikai, you wrote "'ll post some light sample code for channel API and warmup requests in a bit."--

Has that stuff been posted somewhere yet?

On Thu, Nov 18, 2010 at 6:17 PM, Ikai Lan (Google) <ikai.l...@google.com> wrote:

Always On will be a paid feature you enable in the admin console.

I'll post some light sample code for channel API and warmup requests in a bit.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

On Thu, Nov 18, 2010 at 3:11 PM, Sergio Lopes <slo...@gmail.com> wrote:

Excelent news! Specially to protect applications from cold start.
How can I configure WarmUp requests and Always On using Java?

Thanks and congratulations!

On Nov 18, 8:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Ross M Karchner

http://eventgrinder.com

[Adam Sah]

On Nov 22, 10:20 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> I'm seeing only 100-200 downloads of the prerelease SDKs, which you can download here:
> http://code.google.com/p/googleappengine/downloads/list

Ikai-- two bits of feedback...

1. Why so few downloads & feedback?
- no docs, and (I assume) no/few examples.
- unclear if the appspot.com server supports 1.4
i.e. testing the 1.4 pre-release SDK wasn't high enough priority until
one of these conditions is met.

2. While we're chatting, python2.5 -OO is no longer working for
dev_appserver
(while -OO isn't necessarily a priority, it's worth checking that
there aren't other issues...)

drooker>python2.5 -O ~/pkg/google_appengine_1.4.0pre/dev_appserver.py
--help | head -1
Runs a development application server for an application.
...

drooker>python2.5 -O -OO ~/pkg/google_appengine_1.4.0pre/
dev_appserver.py --help
Traceback (most recent call last):
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/
dev_appserver.py", line 69, in <module>
run_file(__file__, globals())
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/
dev_appserver.py", line 65, in run_file
execfile(script_path, globals_)
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/google/appengine/
tools/dev_appserver_main.py", line 503, in <module>
sys.exit(main(sys.argv))
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/google/appengine/
tools/dev_appserver_main.py", line 413, in main
args, option_dict = ParseArguments(argv)
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/google/appengine/
tools/dev_appserver_main.py", line 250, in ParseArguments
PrintUsageExit(0)
File "/ssd1/home/asah/pkg/google_appengine_1.4.0pre/google/appengine/
tools/dev_appserver_main.py", line 188, in PrintUsageExit
print sys.modules['__main__'].__doc__ % render_dict
TypeError: unsupported operand type(s) for %: 'NoneType' and 'dict'

more coming,
adam

[sophware]

looks like the server side is up:

check http://shell.appspot.com/

(screenshot) http://dl.dropbox.com/u/6919071/Captures/2010-12-01_2341.png

Google App Engine/1.4.0
Python 2.5.2 (r252:60911, May 12 2010, 14:18:27)
[GCC 4.3.1]

[Tim Meadowcroft]

On Thursday, December 2, 2010 4:42:55 AM UTC, sophware wrote:

looks like the server side is up:

check http://shell.appspot.com/

(screenshot) http://dl.dropbox.com/u/6919071/Captures/2010-12-01_2341.png

Google App Engine/1.4.0
Python 2.5.2 (r252:60911, May 12 2010, 14:18:27)
[GCC 4.3.1]

Thanks for the heads-up, I'm seeing a server version of 1.4.0 this morning where it was reporting 1.3.8 last night for my app.

I'll wait for official confirmation before assuming it won't be rolled back, but it's looking good (see my Q about the channel API)

--

T

[David Sowerby]

Hi

Thanks for the news. There are many good features in this release -
but for me the most important one is that the development team have
obviously been listening to the feedback and tackling the issues which
matter

Great stuff

On Nov 18, 10:27 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote: