1.8.1 Pre-release SDKs Available.

[Richmond Manzana]

Hello Again Everyone!

We've been busy since I/O!

Pre-release SDKs for Python and Java here:

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

Please see the pre-release notes below.

Cheers,

Richmond Manzana

App Engine Python SDK - Pre-Release Notes

Version 1.8.1

===============================

- The Task Queue async API is now a GA feature. The asynchronous methods

  improve utilization by allowing your app to add, lease and delete multiple

  tasks in parallel.

- Cloud Console projects are now created by default whenever a new App Engine

  app is created.  This is a Preview feature.

- The Experimental Files API has been deprecated in favor of the Google Cloud

  Storage library, now available as a Preview feature.

- Bandwidth between App Engine and Google Cloud Storage is currently free of

  charge (this may change in the future for certain levels of service).

- The Search API has graduated from Experimental to Preview. Apps that have

  billing enabled can exceed the free quota levels and will be charged for

  usage above these levels.

- Estimated number of search results will only be accurate if <= the number of

  results requested. By default this can be overridden by setting

  number_found_accuracy QueryOption in the Search API.

- Dates, atoms, and number fields can now be found by searching without a field

  restriction in the Search API.

- A quoted empty string now returns atom fields with empty values for the

  Search API.

- Snippet and count functions are no longer allowed in sort expressions for the

  Search API.

- The Search API now has improved error messages for user errors and internal

  errors.

- The Datastore now assigns scattered auto ids by default. Legacy auto ids

  are still available via the 'auto_id_policy' option in app.yaml.

- The Sockets API now allows client code to call get/set options against

  sockets. Previously, calls raised "Not Implemented" exceptions. For supported

  options, calls to getsockopt will return a mock value and calls to setsockopt

  will be silently ignored.  Errors will continue to be raised for unsupported

  options. The currently supported options are: SO_KEEPALIVE, SO_DEBUG,

  TCP_NODELAY, SO_LINGER, SO_OOBINLINE, SO_SNDBUF, SO_RCVBUF, and SO_REUSEADDR.

- The ndb library now supports distinct queries. This is a Preview feature.

    https://code.google.com/p/appengine-ndb-experiment/issues/detail?id=229

App Engine Java SDK - Pre-Release Notes

Version 1.8.1

=============

- This SDK will be the last release that can deploy Java 6 apps. In 1.8.2,

  the SDK will only be compiled with the Java 7 compiler and the only target

  runtime will be Java 7.

- The Task Queue async API is now a GA feature. The asynchronous methods

  improve utilization by allowing your app to add, lease and delete multiple

  tasks in parallel.

- Cloud Console projects are now created by default whenever a new App Engine

  app is created.  This is a Preview feature.

- The Experimental Files API has been deprecated in favor of the Google Cloud

  Storage library, now available as a Preview feature.

- Bandwidth between App Engine and Google Cloud Storage is currently free of

  charge (this may change in the future for certain levels of service).

- The Search API has graduated from Experimental to Preview. Apps that have

  billing enabled can exceed the free quota levels and will be charged for

  usage above these levels.

- Estimated number of search results will only be accurate if <= the number of

  results requested. By default this can be overridden by setting X in the

  Search API.

- Dates, atoms, and number fields can now be found by searching without a field

  restriction in the Search API.

- A quoted empty string now returns atom fields with empty values for the

  Search API.

- Snippet and count functions are no longer allowed in sort expressions for the

  Search API.

- The Search API now has improved error messages for user errors and internal

  errors.

- The Datastore now assigns scattered auto ids by default. Legacy auto ids

  are still available via the 'auto_id_policy' option in appengine-web.xml.

- The Sockets API now allows client code to call get/set options against

  sockets. Previously, calls raised "Not Implemented" exceptions. When

  java.net.Socket.get<option>() is called, a mock value is returned, calls to

  set<option>() will be silently ignored.

[Bryce Cutt]

Regarding the Files API deprecation:

Is this as of right now or as of the final release of SDK 1.8.1?

I guess files already written will continue to work as is since they are no different than other blobstore files? Anything wrong with that assumption?

With this announcement, Google's push for use of Cloud Storage, and the lack of a blobstore API in the PHP runtime should we be ready for you guys to announce the deprecation of the blobstore entirely? I hope not. I like the blobstore and how it is nicely and automatically isolated to a single app.

- Bryce

[Doug Anderson]

Could you please clarify this point?

- The Experimental Files API has been deprecated in favor of the Google Cloud

  Storage library, now available as a Preview feature.

Does this mean Blobstore writes are deprecated (I assume so)?

Does it also mean the current Cloud Storage "files" based API is being replaced with an API I have not yet seen?

In other words... https://developers.google.com/appengine/docs/python/googlestorage/functions - is this deprecated?

[Kaan Soral]

+1 on this question
I've been using blobstore for years, it's not so bad, it's bad but not too bad

Should I invest my time and switch to Cloud Storage? (I don't even know how it works, whether it's practical for image like files etc. since blobstore did the job I've never investigated it)

[Bryce Cutt]

So, so I don't misunderstand, when you say "experimental Files API" you are not including this one?

https://developers.google.com/appengine/docs/python/blobstore/blobstorefiles

That is the one I thought was being deprecated when I saw the announcement.

- Bryce

On Tuesday, June 4, 2013 5:07:59 PM UTC-7, Max Ross wrote:

Hi everyone,

I'll try to batch answers to multiple questions into a single response.

1) We're not making any Blobstore announcements or decisions in this release.

2) The only thing we're announcing here is our intent to decommission the experimental Files API. That's

https://developers.google.com/appengine/docs/python/googlestorage/functions and https://developers.google.com/appengine/docs/java/googlestorage/overview

We'll give you fair warning before we actually turn it down. We're announcing this now to give everyone who uses the Files API enough time to move over to the Google Cloud Storage client library, which we're launching in Preview mode.

3) We (very quietly) announced the availability of the Google Cloud Storage client library in a post on this forum back in January. There are full-fledged docs for this library coming out with the official 1.8.1 announcement, including a guide to migrating off the Files API.

I hope this helps.

Thanks,

Max

[Jason Galea]

yeh, same here, but it looks like they should have said "experimental Cloud Files API".. https://developers.google.com/appengine/docs/python/googlestorage/functions

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

--
Jason Galea
lecstor.com

[Chris Ramsdale]

Jason, that is correct -- in a future release we are going to decommission the Experimental Google Cloud Storage API Functions.  These APIs and their Experimental status are documented at the following links:

• https://developers.google.com/appengine/docs/python/googlestorage/functions
  
• https://developers.google.com/appengine/docs/java/googlestorage/overview
  

Given this, we're moving the new Google Cloud Storage Client Library to Preview in the 1.8.1 release. Unlike Experimental features, Preview features are guaranteed to move to General Availability (GA).  We encourage developers to start moving over to the new Cloud Storage Client Library as soon as possible.  Information on getting started can be found at the open source project linked below.

https://code.google.com/p/appengine-gcs-client/

Cheers,

-- Chris Ramsdale

Product Manager, Google App Engine

[jon]

Chris just to clarify, this is not being deprecated is it? https://developers.google.com/appengine/docs/java/blobstore/overview#Writing_Files_to_the_Blobstore

I sure hope not because I'm using it heavily in my apps.

[Tom Kaitchuck]

Jon: The example you are pointing to is using two APIs. In java things under the package: com.google.appengine.api.blobstore are _not_ affected by this announcement. 

Things under the java package: com.google.appengine.api.files are affected by this announcement. 

We will be providing a migration guide for how to change code to use the Google Cloud Storage Client Library. This library is Preview as of 1.8.1 and as such is guaranteed to move to GA. 

Just to emphasize, this is a deprecation announcement, not a decommission. So your application will _not_ break with 1.8.1, but you should begin looking at how to port it to the new library.

If you have questions about how to do this, feel free to create a thread on this group.

On Wed, Jun 5, 2013 at 3:28 AM, jon <jonni...@gmail.com> wrote:

Chris just to clarify, this is not being deprecated is it? https://developers.google.com/appengine/docs/java/blobstore/overview#Writing_Files_to_the_Blobstore

I sure hope not because I'm using it heavily in my apps.

[Doug Anderson]

Thanks for the clarification Chris.  FWIW the blobstore files API (at least in Python) is also not very reliable (I've seen hangs as often as 1 in 10 file create-writes).  So I'll be migrating my blob writes from blobstore to GCS as soon as possible!

From my perspective the blobstore could be deprecated with GCS arrival EXCEPT the following functionality needs to be preserved:

1. The ability to upload files to GCS (of course you can already upload to GCS but this is currently done via the blobstore API).  SOLUTION: gcs.create_upload_url() and  gcs.GCSUploadHandler
2. The ability to serve and transform images via get_serving_url and Image. (again, you can already dynamically serve GCS images but it requires a call to blobstore create_gs_key).  SOLUTION: Update the Images API to directly integrate with GCS everywhere blobstore does!

With the above 2 solutions... I have no need for blobstore (although I'll have some code to migrate)!

[John Wheeler]

The blobstore writing API has been experimental for years now. That being said, I wouldn't be surprised to see Google shut this one down soon too. 

Does GCS support fast concurrent writes the same way the blobstore writing API does? 

[Stefano Ciccarelli]

But this means we will not be able to write programmatically to the blobstore anymore? We will be forced to use GCS instead of blobstore?

—
Sent from Mailbox for iPad

[jon]

Chris and Tom,

I absolutely need programmatic write access to Blobstore, and the Files API is what I'm using at the moment. What alternative will we have?

[Max Ross]

Hi Jon,

The alternative is to programmatically write to Google Cloud Storage. Can you tell me why it's important to write to Blobstore versus GCS?

Thanks,

Max

On Thu, Jun 6, 2013 at 1:41 AM, jon <jonni...@gmail.com> wrote:

Chris and Tom,

I absolutely need programmatic write access to Blobstore, and the Files API is what I'm using at the moment. What alternative will we have?

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/zzpFI5PQbLI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

[John Wheeler]

Max - this is a different Jon (My name is John), but I have the same
concern. Can you please answer whether or not the GCS supports fast

concurrent writes the same way the blobstore writing API does?

[Max Ross]

Hi Different John,

If you're trying to write to the same File from multiple threads on the same instance you'll be fine. The writes are done asynchronously so they should be fast. If you need to write to the same File from multiple instances, we recommend you instead create 1 GCS File per instance and then use the compose feature:

https://developers.google.com/storage/docs/json_api/v1/objects/compose

Thanks,

Max

[Mike]

Hi Max

The issue for us would be that we now have millions of images written to Blobstore, all with publicly facing URLs... moving those to Cloud Storage would likely be expensive and disruptive unless Google can automatically manage that for us.

What I would hate is to have to run 2 systems in parallel: 1 legacy, 1 "shiny new object".

Mike :-)

[Thiago Catoto]

-1 for deprecation of the blobstore

:'(

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.

[Chris]

Max,

What's the timetable on the experimental Files API decommission:

2 Months, 6 Months or a year?

So we can all plan the urgency of this conversion...

- Chris

On Tuesday, June 4, 2013 8:07:59 PM UTC-4, Max Ross wrote:

Hi everyone,

I'll try to batch answers to multiple questions into a single response.

1) We're not making any Blobstore announcements or decisions in this release.

2) The only thing we're announcing here is our intent to decommission the experimental Files API. That's

https://developers.google.com/appengine/docs/python/googlestorage/functions and https://developers.google.com/appengine/docs/java/googlestorage/overview

We'll give you fair warning before we actually turn it down. We're announcing this now to give everyone who uses the Files API enough time to move over to the Google Cloud Storage client library, which we're launching in Preview mode.

3) We (very quietly) announced the availability of the Google Cloud Storage client library in a post on this forum back in January. There are full-fledged docs for this library coming out with the official 1.8.1 announcement, including a guide to migrating off the Files API.

I hope this helps.

Thanks,

Max

On Tuesday, June 4, 2013 2:13:19 PM UTC-7, Kaan Soral wrote:

[pdknsk]

> 1) We're not making any Blobstore announcements or decisions in this
> release.

Translation: It'll be deprecated when we have figured out how to best
communicate it.

[Stefano Ciccarelli]

As already happened for the Conversion APIs, we are required to throw away the investment of time and money as users of experimental APIs.

Me and my team will never use again experimental APIs because the risk begins to be too high.

The problem of not being able to write programmatically on blobstore forces us to rethink the ways in which the files are moved within our application and introduces heterogeneity rather than the current homogeneity.

We too will probably be forced to spend money to migrate the data already stored with an economic cost on our part.

Besides the fact that I do not know what will happen now with the Image APIs that allow you to serve images directly from blobstore. Besides the fact that I do not know what will happen with the current upload mechanism in blobstore and if exist something similar for GCS: I would not use GCS to write a file programmatically and use blobstore to upload a file.

Then we talk about the economic theme, the blobstore has a free quota while GCS not.

In short it is a new disappointment: developing on GAE platform is like a flag in the wind, you never know what direction will have in the next five minutes.

2013/6/6 Max Ross <ma...@google.com>

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.

To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Nel mondo esistono 10 categorie di persone, quelle che capiscono il binario e quelle che non lo capiscono.

[Alexis]

Regarding:

- The Task Queue async API is now a GA feature. The asynchronous methods

  improve utilization by allowing your app to add, lease and delete multiple

  tasks in parallel.

Could you also update "deferred.defer" to expose an asynchronous method as well?

[Kaan Soral]

strong +1 :)
an update to defer would be great, also it would be great if the function would be automatically wrapped around a ndb.toplevel while you're at it

[Moises Belchin]

Alexis +1

Kaan +1

deferred.defer in asynchronous would be awesome !!!

Saludos.

Moisés Belchín.

2013/6/7 Kaan Soral <kaan...@gmail.com>

--

[jon]

Hi Max,

There are two components in this issue, both of which are important to us:

1. The Blobstore itself
2. Programmatic write to Blobstore

1. We take advantage of in-built Blobstore features for storing and serving images. Our mobile apps have been designed to consume images in a Blobstore-specific way. Moving to GCS would require "deprecating" all these app installations.

2. We store images by using the Files API to programmatically write to Blobstore. The "non-programmatic write" alternative proved to be unsuitable (too slow) for mobile apps because it would result in too many HTTP request/response cycles.

If you're going to deprecate the Files API, please provide an alternative to write to Blobstore programmatically.

Thank you.

[Chris]

Max,

Any insight on the decommissioning timeline? We have a lot if code dependent on that API.

- Chris

[jon]

Just letting fellow GAE users know that Max Ross from Google has sent an email to discuss my Blobstore concerns.

I'd like to publicly thank Max for proactively chasing up with developers.

[Chris]

Jon,

Any word on the timeline?

- Chris

[Chris Ramsdale]

hey Chris, et al.--

a bunch of great feedback that we'll continue to address.  in regards to timeline, we have no plans of decommissioning this API before end of year. that said, assuming the following:

• App Engine <=> Google Cloud Storage performance is equivalent to (if not better than) App Engine <=> Blobstore
• all blobs were auto-migrated over to Cloud Storage (free of charge)
  
• all existing URLs just worked

what would keep you from migrating over to a Cloud Storage-based solution?

-- Chris

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.

[Stefano Ciccarelli]

The blobstore free daily quota :)

—
Sent from Mailbox for iPad

[Chris Ramsdale]

noted, and already looking into this.  would you need the free quota spread across multiple buckets or would you be good with the free daily quota applied to a single bucket?

-- Chris

[Chris]

Chris,

That seems fair -- We're happy now.

- Chris

[Stefano Ciccarelli]

The free quota spread over multiple buckets would be better, but I think that a free quote applied to a single bucket could be fair. We can consider the actual blobstore as a single bucket. 

—
Sent from Mailbox for iPad

[Alex Burgel]

On Saturday, June 8, 2013 2:04:23 AM UTC-4, Chris Ramsdale wrote:

what would keep you from migrating over to a Cloud Storage-based solution?

1. Its a bit of a pain to get set up with cloud storage, especially all the service name account and permissions stuff. Blobstore is nice because it just works.

2. I have mobile clients which use the blobstore upload system. I would want the existing clients to continue to work if I migrated to cloud storage. I looked into the cloud storage API and you couldn't exactly mimic the blobstore protocol.

3. Blobstore doesn't require unique filenames. so when uploading files, I hardcode in a file name since it doesn't matter. To switch to cloud storage, I'd have to come up with a unique filename.

--Alex

[Vinny P]

Hi Chris, thanks for stopping by.

My need: Better libraries.

What I liked about the Files API (and particularly in regards to the Blobstore) is that it made writing files so unbelievably easy. For example, in Java all I needed to do was get an instance of FileService, then I could write and read using openWriteChannel/openReadChannel. The Files API handled the dirty part of configuring access to the datastore, managing the write, etc. Frankly, I think the Files API is one of the best engineered parts of GAE (give whoever wrote that API a raise and a promotion please!).

But you look at the javadoc for the Java Cloud Storage library, and it's an utter mess. See for yourself: https://developers.google.com/resources/api-libraries/documentation/storage/v1beta2/java/latest/ . For one, there's not enough examples. Two, I have to mess around with BucketAccessControls and Builders and a whole mess of things. Chris, I just want to write some files to persistent storage, I don't want to have to micromanage everything else and deal with extra fluff. I'll micromanage if I have to, but the Blobstore took care of that for me.

Get the guy who wrote the Files API and put him to work on writing the GCS library.

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

-Vinny P

Technology & Media Advisor

Chicago, IL

My Go side project: http://invalidmail.com/

[Jeff Schnitzer]

On Fri, Jun 7, 2013 at 11:04 PM, Chris Ramsdale <cram...@google.com> wrote:

hey Chris, et al.--

a bunch of great feedback that we'll continue to address.  in regards to timeline, we have no plans of decommissioning this API before end of year. that said, assuming the following:

• App Engine <=> Google Cloud Storage performance is equivalent to (if not better than) App Engine <=> Blobstore
• all blobs were auto-migrated over to Cloud Storage (free of charge)
  
• all existing URLs just worked

what would keep you from migrating over to a Cloud Storage-based solution?

Some questions:

 * Will the current upload mechanism be preserved? Looking through the docs it appears the answer is that you create a signed url directly into GCS and have the client POST/PUT it, which seems like it should be compatible with the existing BlobstoreService.getUploadUrl() approach. But how do we get notification when the upload is complete? Right now the blobstore upload mechanism gives us a callback, and I do important things on this callback.

 * Will this work with the image service the way the blobstore does now? I transform, resize, and crop images on the fly - this rarely-lauded feature is actually one of my favorite parts of GAE.

 * Will existing blobstore-based image urls be preserved? I have a lot of these in my datastore.

 * What does the GAE dev environment do with the GCS apis? What about the Local Unit Testing framework?

As long as there are sane answers to these questions, I have no objection to GCS... although it will require that I rewrite and some code:

 * I read PDF data out of the blobstore using the files api, send it off to a service for transformation into an image, then write the image back to the blobstore. This sounds pretty straightforward with GCS.

 * I de-dup all uploaded images using the hash, and track image references. This means I have a lot of data referencing BlobKeys in the datastore. This brings up the question, if data is migrated from Blobstore to GCS, what are the new keys? Will it be clear how to migrate this data?

I don't object to rewriting code as long as the migration path is clear. I can appreciate consolidating development effort around a single blobstore-ish offering.

Thanks,

Jeff

[jon]

I will migrate to GCS if:
* All conditions stated by Chris Ramsdale are met
* It is fully compatible with Blobstore's dynamic resize feature (eg the =s parameter still works)
* It allows for a file upload (especially from mobile apps) to be completed in one HTTP request
* It sets far future expiry header

+1 to everything Jeff said.

[Brent Washburne]

+1 to everything jon said.

[Bryce Cutt]

My blobstore filenames are definitely not unique. In many cases there
are over 50,000 files with the same default filename. I don't use the
filename for anything. I just use the blobkey. Also, my users upload
files and I have never had a need to check for filename uniqueness.
This could be an issue if Google makes some auto-migration script that
copies all my data into a GCS bucket.

I share many of Jeff's concerns as I use blobstore upload handlers and
images api integration a lot. Also really curious how the lack of a
blobstore will affect local testing.

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Google App Engine" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/zzpFI5PQbLI/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to

[Mike]

Hi Chris

That would work for me, provided there was an easy way to get a public Picasa URL for an uploaded image, etc. Thanks :)

Mike

[Tom Kaitchuck]

Vinny: 

The intended replacement for the FilesAPI is not the library you link to, but the one here: https://code.google.com/p/appengine-gcs-client/
It is very deliberately modeled after the FilesAPI.

[Tom Kaitchuck]

Jeff: Replies inline

On Sat, Jun 8, 2013 at 9:49 AM, Jeff Schnitzer <je...@infohazard.org> wrote:

Some questions:

 * Will the current upload mechanism be preserved? Looking through the docs it appears the answer is that you create a signed url directly into GCS and have the client POST/PUT it, which seems like it should be compatible with the existing BlobstoreService.getUploadUrl() approach. But how do we get notification when the upload is complete? Right now the blobstore upload mechanism gives us a callback, and I do important things on this callback.

This will continue to function as it does now. This api is not affected.

 

 * Will this work with the image service the way the blobstore does now? I transform, resize, and crop images on the fly - this rarely-lauded feature is actually one of my favorite parts of GAE.

Yes. In fact you can already use the image service with files in GCS and blobstore using the same API. 

 

 * Will existing blobstore-based image urls be preserved? I have a lot of these in my datastore.

Today's announcement will have no effect on files store in blobstore.

 

 * What does the GAE dev environment do with the GCS apis? What about the Local Unit Testing framework?

It will work and use local disk as the backing store.

 

As long as there are sane answers to these questions, I have no objection to GCS... although it will require that I rewrite and some code:

 * I read PDF data out of the blobstore using the files api, send it off to a service for transformation into an image, then write the image back to the blobstore. This sounds pretty straightforward with GCS.

 * I de-dup all uploaded images using the hash, and track image references. This means I have a lot of data referencing BlobKeys in the datastore. This brings up the question, if data is migrated from Blobstore to GCS, what are the new keys? Will it be clear how to migrate this data?

You can generate a BlobKey from an Item in GCS so this code would not need to be changed much.

Data migration is not being done, nor is it necessary for you to plan for at this time.

[Tom Kaitchuck]

Jon the three criteria you specify are all available today:

You can use the Images API with files in GCS by getting a blobKey for them which can be done by calling getBlobKey.

File upload is supported.

Headers can be specified at upload time.

[GAEfan]

I think the confusion is based on the fact that there is a Blobstore, and also a Blobstore API.  The Blobstore API can be used with files stored in the Blobstore, *OR* with files stored in GCS.

It is a rather confusing naming convention.  I might suggest a parallel "renamed-as-gcs" API, with the same functions as Blobstore API.  That may avoid future confusion, and make for cleaner code.

blobstore.create_gs_key(blobstore_filename)

blobstore.fetch_data(blob_key, 0, 2))

blobstore.delete(blob_key)

blobstore_handlers.BlobstoreDownloadHandler

all rather confusing when using Google Cloud Storage, and not the Blobstore.

[Doug Anderson]

Below is a tested python example showing how to write a JPEG to both GCS using the "new" API and Blobstore.  Note how VERY similar the process is (all things considered).  IMO Google did a terrific job making this inevitable transition mostly seamless.  The only possible prerequisite setup required is to add your GAE service account name as a team member in the Google APIs console where you enable/manage the Cloud Storage service... as described in step #5 here: https://developers.google.com/appengine/docs/python/googlestorage/

Note: Both examples below assume "img_data" contains JPEG image data such as from

an images service transformation

    

#----------------------------------------------------------

# GCS image write & serving url

# Assumes: import cloudstorage as gcs

#----------------------------------------------------------

GCS_NAME_CHARS = string.ascii_letters + string.digits

rand = random.SystemRandom()

gcs_bucketname = '/yourbucket/'

# Create a random 32 char GCS filename

gcs_objectname = ''.join([rand.choice(GCS_NAME_CHARS) for _ in range(32)])

# Create and write the image data to the GCS object

gcs_fullname = gcs_bucketname + gcs_objectname

with gcs.open(gcs_fullname, 'w', content_type='image/jpeg') as gcs_file:

    gcs_file.write(img_data)

gcs_file.close()

gcs_key = blobstore.create_gs_key('/gs' + gcs_fullname)

serving_url = images.get_serving_url(gcs_key)

#----------------------------------------------------------

# Blobstore image write & serving url

#----------------------------------------------------------

# Create and write the image data to the blobstore file

bs_filename = files.blobstore.create(mime_type='image/jpeg')

with files.open(bs_filename, 'a') as bs_file:

    bs_file.write(img_data)

files.finalize(bs_filename)

# Get the serving url

blob_key = files.blobstore.get_blob_key(bs_filename)

serving_url = images.get_serving_url(blob_key)

On Tuesday, June 4, 2013 2:46:22 PM UTC-4, Richmond Manzana wrote:

Hello Again Everyone!

We've been busy since I/O!

Pre-release SDKs for Python and Java here:

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

Please see the pre-release notes below.

Cheers,

Richmond Manzana

App Engine Python SDK - Pre-Release Notes

Version 1.8.1

===============================

- The Task Queue async API is now a GA feature. The asynchronous methods

  improve utilization by allowing your app to add, lease and delete multiple

  tasks in parallel.

- Cloud Console projects are now created by default whenever a new App Engine

  app is created.  This is a Preview feature.

- The Experimental Files API has been deprecated in favor of the Google Cloud

  Storage library, now available as a Preview feature.

- Bandwidth between App Engine and Google Cloud Storage is currently free of

  charge (this may change in the future for certain levels of service).

- The Search API has graduated from Experimental to Preview. Apps that have

  billing enabled can exceed the free quota levels and will be charged for

  usage above these levels.

- Estimated number of search results will only be accurate if <= the number of

  results requested. By default this can be overridden by setting

  number_found_accuracy QueryOption in the Search API.

- Dates, atoms, and number fields can now be found by searching without a field

  restriction in the Search API.

- A quoted empty string now returns atom fields with empty values for the

  Search API.

- Snippet and count functions are no longer allowed in sort expressions for the

  Search API.

- The Search API now has improved error messages for user errors and internal

  errors.

- The Datastore now assigns scattered auto ids by default. Legacy auto ids

  are still available via the 'auto_id_policy' option in app.yaml.

- The Sockets API now allows client code to call get/set options against

  sockets. Previously, calls raised "Not Implemented" exceptions. For supported

  options, calls to getsockopt will return a mock value and calls to setsockopt

  will be silently ignored.  Errors will continue to be raised for unsupported

  options. The currently supported options are: SO_KEEPALIVE, SO_DEBUG,

  TCP_NODELAY, SO_LINGER, SO_OOBINLINE, SO_SNDBUF, SO_RCVBUF, and SO_REUSEADDR.

- The ndb library now supports distinct queries. This is a Preview feature.

    https://code.google.com/p/appengine-ndb-experiment/issues/detail?id=229

App Engine Java SDK - Pre-Release Notes

Version 1.8.1

=============

- This SDK will be the last release that can deploy Java 6 apps. In 1.8.2,

  the SDK will only be compiled with the Java 7 compiler and the only target

  runtime will be Java 7.

- The Task Queue async API is now a GA feature. The asynchronous methods

  improve utilization by allowing your app to add, lease and delete multiple

  tasks in parallel.

- Cloud Console projects are now created by default whenever a new App Engine

  app is created.  This is a Preview feature.

- The Experimental Files API has been deprecated in favor of the Google Cloud

  Storage library, now available as a Preview feature.

- Bandwidth between App Engine and Google Cloud Storage is currently free of

  charge (this may change in the future for certain levels of service).

- The Search API has graduated from Experimental to Preview. Apps that have

  billing enabled can exceed the free quota levels and will be charged for

  usage above these levels.

- Estimated number of search results will only be accurate if <= the number of

  results requested. By default this can be overridden by setting X in the

  Search API.

- Dates, atoms, and number fields can now be found by searching without a field

  restriction in the Search API.

- A quoted empty string now returns atom fields with empty values for the

  Search API.

- Snippet and count functions are no longer allowed in sort expressions for the

  Search API.

- The Search API now has improved error messages for user errors and internal

  errors.

- The Datastore now assigns scattered auto ids by default. Legacy auto ids

  are still available via the 'auto_id_policy' option in appengine-web.xml.

- The Sockets API now allows client code to call get/set options against

  sockets. Previously, calls raised "Not Implemented" exceptions. When

  java.net.Socket.get<option>() is called, a mock value is returned, calls to

  set<option>() will be silently ignored.

[Doug Anderson]

... the "gcs_file.close()" line is not needed (I forgot to remove it when I changed to use the "with" statement)

[GAEfan]

Thanks, Doug.  That is very helpful.

My first thought was that you don't test to see if "gcs_objectname" already exists.  But, I guess 1/ 2e57 is close enough to zero for most apps.

[Doug Anderson]

yep... a risk I'm willing to live with... but you could increase the file name length, increase the set of GCS_NAME_CHARS, and/or add exception handling if it's a concern for you... just remember the max GCS objectname length is 1024 bytes of UTF-8 encoded chars.