Re: [google-appengine] Re: Announcing SSL for Custom Domains Trusted Tester Program

[Doug Anderson]

Thanks for the update Cayden.  It's reassuring to know SSL on custom 
domains is still alive and high priority with the GAE team.

I can certainly appreciate the desire and temptation to offer a nice, clean 
SNI solution.  However, I think today's client compatibility reality 
doesn't allow for an SNI solution.  The main culprits are pre-ICS Android 
and Blackberry clients more so than IE on Win-XP.  At least on Win-XP 
Chrome and FireFox are viable alternatives to IE.  Whereas Android 
incompatibility includes the Kindle Fire and the overwhelming majority of 
Android phones on the market today.  It just doesn't make sense for a 
modern website to deliberately disregard the certificate warnings its users 
will experience with those clients.  The warnings leave an unprofessional 
blemish on the site and likely leave the user confused and questioning the 
site's integrity and professionalism.

My hope is that Google will stick with the SNI path for possible future 
deployment but realize that VIP is the only practical approach at this 
point in time.  This means VIP would need to be offered at an affordable 
price point or perhaps even made available for free.  I can only imagine 
the cost and challenges involved with developing a robust VIP solution in 
the cloud environment.  However, every once in a while a feature is 
significant enough to overlook the NRE and do the right thing in lieu of 
trying to directly recoup costs.  I would argue that SSL on custom domains 
is such a feature.  A proper, affordable SSL solution promotes a secure web 
and benefits the GAE platform.

I wish SNI had been a part of the original TLS spec but unfortunately that 
didn't happen and now we are forced to wait several more years for 
significantly more incompatible clients to flush out of the ecosystem.  The 
alternative is to support SNI and pollute the web with certificate warnings 
when Android and Blackberry clients visit certain GAE sites.  I don't think 
anybody wants this and I hope Google does the right thing.

  - Doug Anderson

On Sunday, April 22, 2012 7:01:22 PM UTC-4, Cayden Meyer wrote:
>
> Hi Everyone, 
>
> SSL for Custom Domains is still undergoing testing and improvement. 
>
> I do not have a timeline to announce at this point, but rest assured that 
> this is a priority for the App Engine team and it is a feature we are 
> committed to launching. 
>
> Thanks,
>
> Cayden Meyer
> Product Manager, Google App Engine
>
> On 20 April 2012 23:54, James Gilliam  wrote:
>
>> How about some status?
>>
>> On Mar 28, 3:34 pm, Kaan Soral  wrote:
>> > What is the current status of SSL for Custom Domains, when can we 
>> expect it
>> > in production?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Monday, October 17, 2011 11:13:14 AM UTC+3, Cayden Meyer wrote:
>> >
>> > > Hey everyone,
>> >
>> > > I am pleased to announce that we are accepting signups for the SSL for
>> > > custom domains Trusted Tester Program. This will allow you to serve
>> > > secure traffic for your App Engine application from your own
>> > > domain(https://your.domain.com) rather than your appspot.com domain
>> > > (https://your-app-id.appspot.com).
>> >
>> > > We will be offering two types of SSL service, Server Name Indication
>> > > (SNI) and Virtual IP(VIP). SNI will be significantly less expensive
>> > > than VIP when this service is fully launched, however unlike VIP it
>> > > does not work everywhere SSL is supported, notably it is not supported
>> > > by IE and Safari on Windows XP. Multiple certificates are supported by
>> > > SNI, while the VIP service only supports a single certificate per
>> > > virtual IP address. Wildcard certificates and certificates with
>> > > alternate names are supported by both SNI and VIP.
>> >
>> > > Either a Free or Paid Google Apps account is required to use SSL. The
>> > > use of multiple domains is supported via the aliasing feature in
>> > > Google Apps.
>> >
>> > > If you are interesting in signing up to test this feature, please fill
>> > > in the form linked below.
>> >
>> > >https://docs.google.com/a/google.com/spreadsheet/viewform?formkey=dHF.
>> ..
>> >
>> > > Currently we are testing on a limited basis and will not be able to
>> > > accept everybody who applies to the trusted tester program.
>> >
>> > > As with all trusted tester programs, documentation is a work in
>> > > progress.
>> >
>> > > This feature is still in testing an

Re: [google-appengine] Re: Announcing SSL for Custom Domains Trusted Tester Program

[Doug Anderson]

>
> Thanks for the update Cayden... it's nice to know this issue is still 
> alive and high priority!
>
 

> For me the biggest issue with SNI is pre-ICS Android and Blackberry more 
> than IE (or Safari) with Windows-XP.  I can appreciate the desire and 
> temptation for an SNI solution but the reality is that there are still too 
> many non-compliant clients out there for SNI to be an adequate solution for 
> 99% of sites.  I wish SNI had been part of the original TLS spec but 
> unfortunately that isn't the case and we still have several years before 
> enough non-compliant clients are flushed from the ecosystem to make SNI a 
> viable solution.  Practically every Android phone (non Ice Cream Sandwich) 
> and many Android tablets including the Kindle Fire issue certificate 
> warnings with SNI today.  So if you care about Android / Kindle Fire / 
> Blackberry / IE-XP clients then SNI isn't for you.  The fact is if you use 
> SNI today your site will have an unprofessional blemish with the numerous 
> non-compliant clients and will result in a sub-standard user experience and 
> possibly support calls.
>
 

> So my hope is that Google keeps the SNI effort alive for future use but 
> makes VIP the recommended, affordable, and perhaps only solution for 
> today's GAE apps.  Since any non-trivial site should be using SSL today to 
> protect session data etc., I hope Google does the right thing to support 
> proper secure computing on its flagship platform.  I can only imagine the 
> cost and challenges involved with getting the VIP solution to work in the 
> cloud environment but every once in a while a feature comes along that you 
> just need to support because its the right thing to do and not to recoup 
> associate costs and make a big profit.  I would argue that (VIP) SSL is one 
> of those features.  It's something the GAE team can do simply because 
> they're Google and a leading steward of the Internet.  The alternate is to 
> pollute the web with certificate warnings, the majority of which will 
> likely be on its own Android platform.
>
 

> While we await this vital missing piece of an otherwise awesome GAE 
> platform you can test your client browsers responses to SNI here: 
>  https://sni.velox.ch/
>
 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/7m0-QAOuQdUJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Announcing SSL for Custom Domains Trusted Tester Program

[Doug Anderson]

Thanks for the update Cayden.  It's reassuring to know SSL on custom 
domains is still alive and high priority with the GAE team.

I can certainly appreciate the desire and temptation to offer a nice, clean 
SNI solution.  However, I think today's client compatibility reality 
doesn't allow for an SNI solution.  The main culprits are pre-ICS Android 
and Blackberry clients more so than IE on Win-XP.  At least on Win-XP 
Chrome and FireFox are viable alternatives to IE.  Whereas Android 
incompatibility includes the Kindle Fire and the overwhelming majority of 
Android phones on the market today.  It just doesn't make sense for a 
modern website to deliberately disregard the certificate warnings its users 
will experience with those clients.  The warnings leave an unprofessional 
blemish on the site and likely leave the user confused and questioning the 
site's integrity and professionalism.

My hope is that Google will stick with the SNI path for possible future 
deployment but realize that VIP is the only practical approach at this 
point in time.  This means VIP would need to be offered at an affordable 
price point or perhaps even made available for free.  I can only imagine 
the cost and challenges involved with developing a robust VIP solution in 
the cloud environment.  However, every once in a while a feature is 
significant enough to overlook the NRE and do the right thing in lieu of 
trying to directly recoup costs.  I would argue that SSL on custom domains 
is such a feature.  A proper, affordable SSL solution promotes a secure web 
and benefits the GAE platform.

I wish SNI had been a part of the original TLS spec but unfortunately that 
didn't happen and now we are forced to wait several more years for 
significantly more incompatible clients to flush out of the ecosystem.  The 
alternative is to support SNI and pollute the web with certificate warnings 
when Android and Blackberry clients visit certain GAE sites.  I don't think 
anybody wants this and I hope Google does the right thing.

  - Doug Anderson

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/8yEFneGBHzUJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: SSL support

[Doug Anderson]

I share your sentiment about the SSL support 100%... it's great to finally 
have it but the reality is the ecosystem just isn't ready for SNI yet. 
 There are still too many browsers that don't support SNI including the 
Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which 
there are many).   To be honest I expect Google to be a better steward of 
the Internet.  Proper SSL support should be encouraged and offered as an 
inherent part any professional web development platform.  SSL should NOT be 
treated as a major feature upgrade where cost becomes a deciding factor for 
adoption.  By favoring SNI Google is compromising the integrity of the 
browser experience anytime the overwhelming majority of Android users 
browse to a secure App Engine site.

The non-SNI supporting browsers I've tested generate big ol' certificate 
warnings and strongly encourage users NOT to continue browsing to the site. 
 Users generally have a choice to continue or not but the warnings sound 
quite ominous and make it seem like your illegitimate site is pretending to 
be someone else's legitimate site ("the certificate this site is using was 
issued for another web address").  Unfortunately, adopting SNI right now 
just pollutes the browsing experience and makes your site seem shady.   
With Internet Explorer if the user clicks through the certificate warning 
and continues to you site, the URL input bar stays highlighted with a red 
background and an intimidating "certificate error" message is displayed to 
the right of the URL.

I'm all for Google profiting from App Engine but it seems like there are 
enough other opportunities for that since they monitor and charge for just 
about everything else.  I'm still hoping there's enough "don't be evil" 
within Google that they decide to favor a seamless browsing experience over 
a pay-for-proper-security profit grab.  Perhaps in another 3-5 years the 
ecosystem will be more accommodating of SNI but unfortunately that day 
isn't here yet.

On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
>
> So happy to see SSL support finally here, but a bit disappointed.  VIP 
> seems the way to go, but at $99 per month, it is cost prohibitive for some 
> of our apps.  So, I am asking for feedback from others who have implemented 
> SNI.  From my understanding, there are still many visitors with older 
> browsers who will not be able to use it.  Is that correct?
>
> Looking at recent stats, we have 16% of our visitors with IE 6 or 7.  And 
> an astounding 43% with XP or previous versions of Windows.  Not to mention 
> those with Safari/Win, or older Android OS.  What will these visitors see 
> when they try to access an SNI-SSL page?
>
> Any problems/issues encountered with SNI implementations?  Older browsers? 
>  International visitors?  Frankly, at $108/year PLUS the certificate, even 
> SNI-SSL is expensive.  But $1200/year, plus cert, for VIP is not feasible 
> for smaller apps.  (IMO, $108/year should cover virtual IP).  Sticking with 
> our appspot URLs for SSL until this is ready for prime time.  We are not 
> willing to abandon even a small single-digit percentage of our users.
>
> Also, I recently was told that some search engines use the IP address in 
> page ranking.  Shared IPs are penalized.  Had not heard that before, and 
> not sure that is accurate, as a majority of sites are on shared-IPs.
>
> Your feedback greatly appreciated.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/HUXzIEE43doJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Sending emails from gae using mailgun

[Doug Anderson]

I use mailgun with GAE... it works with local development environment and 
deployed production environment.  Their support is awesome and the web 
service is lightning fast.  I moved to mailgun because my app requires more 
flexibility than what the native GAE email capabilities provide 
(specifically I needed additional sender capability).  The other mail 
service I'd consider is http://postmarkapp.com/ which now also offers an 
inbound email web service (they can invoke your HTTP handler) similar to 
mailgun.  I still prefer mailgun though.  Many other email services are 
purely geared towards outbound mail and limit inbound to mail protocols 
such as pop, imap, etc... vs calling an http handler asynchronously.


On Friday, November 9, 2012 4:30:46 PM UTC-5, Emmanuel Mayssat wrote:
>
> I am writing an app that requires email to be sent (notifications)
> I am contemplating using mailgun as a service.
>
> 1/ I s there a email web service you recommended?
>
> I can send emails through mailgun using the 'request' python module
>
> def send_simple_message():
> data = {"from": "Excited User 
> >",
>   "to": ["t...@gmail.com ", 
> "to...@outlook.com"], 
> #
>   "subject": "[https] Hello Mama (REQUEST)",
>   "text": "Testing some Mailgun awesomness!"}
> return requests.post(
> mailgun_url,
> auth = HTTPBasicAuth(username, password), 
>   # <-- or simply auth=(username, password)
> data = data )
>
> I can also send emails from the shell using urllib2 (More complex because 
> of https)
>
> Cutting and pasting my urllib2 code in my gae app doesn't report any error 
> or anything else
>
> 2/ Can email be send when using the local gae server or the app have to be 
> fully deployed?
>
> 3/ Is there a way to send emails through google app engine? (including for 
> users that do not have gmail accounts)
>
> 4/ I cannot make sense of the gae policy as far as sending emails
> What are administrator password?
> Where are the administrator accounts?
> My domain is not hosted on gae.
> I am just using gae for test right now.
>
> Regards
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/uQorsITU44gJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Taskqueue execution latency up by 1000x

[Doug Anderson]

Have you tried increasing the bucket_size above the default value of 5 
and/or the processing rate above 5/s?  I'm not saying there isn't a bug... 
I'm just curious if there's a workaround or if perhaps the problem is 
triggered by exceeding some threshold from which task queue manager never 
properly recovers.

On Tuesday, November 13, 2012 11:57:47 AM UTC-5, Dan wrote:
>
> Thanks for the info.
>
> Looks like I spoke too soon as well, taskqueue execution latency is back 
> up again - awesome. If only the latency increase was in the order of 10x 
> not a massive 100x - 1000x...
>
> On Tuesday, November 13, 2012 1:40:58 PM UTC, stevep wrote:
>>
>> This issue has been raised before (I believe this is what you are 
>> seeing). Many moons ago vlad was its champion in these groups. His 
>> conclusion (link below): "I have been screaming about this for a looong 
>> time. The offcial position of GAE team is - we don't guarantee on time 
>> execution. Even though this issue is not about on time execution but rather 
>> about bugs/inefficiency of their scheduler." 
>>
>> Sadly I think this is never going away, so best to build your client with 
>> the anticipation of such delays -- TQ tasks as part of handling client 
>> calls are too powerful/necessary to avoid entirely. HTH -stevep
>>
>> Link:
>>
>> https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/nwnq7cjABhY
>>
>>
>>
>> On Sunday, November 11, 2012 2:43:06 AM UTC-8, Dan wrote:
>>>
>>> Hi Goggle,
>>>
>>> Is it possible to have an update as to what's going on with the 
>>> taskqueue execution latency. According to the status monitor it has been 
>>> going on since midnight on 10th November and is still continuing.
>>>
>>> There are no notes to say you are looking into it so I just wanted to 
>>> make sure you are aware of it.
>>>
>>> The pattern I am seeing is that multiple tasks are delayed for over a 
>>> minute and then execute all at once. My app is used to an execution latency 
>>> in the order of < 10ms but I am seeing delays of over 60,000ms.
>>>
>>> Best wishes,
>>> Dan
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/-EI5yWqYQmMJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Can anyone confirm or deny that round about 1st March, GoogleAppEngine trippled the length of Blobstore filenames from around 300 chars up to around 900 chars?

[Doug Anderson]

Can you also please fix issue 5236 since files.blobstore.create() still 
fails 1-2% of the time due to timeout (it hangs in google coded as 
explained in issue)?
https://code.google.com/p/googleappengine/issues/detail?id=5236

On Tuesday, March 5, 2013 9:38:10 PM UTC-5, Ryan Huebsch wrote:
>
> We've filed an issue 
> https://code.google.com/p/googleappengine/issues/detail?id=8932 to track 
> the issue and have begun investigating.
>
> On Tuesday, March 5, 2013 6:39:44 AM UTC-8, Andrew Bindon wrote:
>>
>> Can anyone confirm or deny that round about 1st March, GoogleAppEngine 
>> trippled the length of Blobstore filenames from around 300 chars up to 
>> around 900 chars?
>>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@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.

[google-appengine] Re: 1.8.1 Pre-release SDKs Available.

[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?


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 

Re: [google-appengine] Re: 1.8.1 Pre-release SDKs Available.

[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)!

On Tuesday, June 4, 2013 10:20:49 PM UTC-4, Chris Ramsdale wrote:
>
> 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 
> Libraryto 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
>
>
> On Tue, Jun 4, 2013 at 6:34 PM, Jason Galea 
> > wrote:
>
>> yeh, same here, but it looks like they should have said "experimental 
>> Cloud Files API".. 
>> https://developers.google.com/appengine/docs/python/googlestorage/functions
>>
>>
>> On Wed, Jun 5, 2013 at 11:27 AM, Bryce Cutt 
>> > wrote:
>>
>>> 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/functionsand
  
 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 
 poston
  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:
>
> +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)
>
> On Tuesday, June 4, 2013 11:45:35 PM UTC+3, Bryce Cutt wrote:
>>
>> 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, Goog

[google-appengine] Re: 1.8.1 Pre-release SDKs Available.

[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

[google-appengine] Re: 1.8.1 Pre-release SDKs Available.

[Doug Anderson]

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

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() is called, a mock value is returned, calls 
> to
>   set() will be silently ignored.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving em

[google-appengine] Re: 1.8.1 Pre-release SDKs Available.

[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.

On Tuesday, June 11, 2013 6:21:36 PM UTC-4, GAEfan wrote:
>
> 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.
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@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.

[google-appengine] Request to add jinja v2.7 to python sdk and live runtime environment

[Doug Anderson]

Please consider adding jinja 2.7 to the python SDK and live runtime 
environment.  Thanks.

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Writes to cloud storage hanging after opening file?

[Doug Anderson]

   
   1. Why hasn't the GCS client download been updated since early June? 
Numerous changes have been checked in since then.  As I understand it one 
   of them is crucial to GCS reliability.
   2. Why hasn't the GCS client been integrated into the App Engine SDK / 
   Runtime.  This seems like the best way to ensure developers are using the 
   latest-approved version.
   3. These 'hangs' are reminiscent of the unreliability of the deprecated 
   files API... my hope remains that GCS can become MUCH more reliable in the 
   very near future!
   4. On a side note... the python SDK installation can take A LONG time... 
   I believe this is largely due to more and more Django versions getting 
   added to the SDK.  Without Django versions v0.96 thru v1.5 the uncompressed 
   SDK size drops from 138MB to 24MB (from 19k+ files to just 1.9k files). 
I'm a Django fan but I'm not using it at the moment with App Engine... it 
   would be nice if the Django installation was optional and/or let you select 
   the versions of Django to install... I doubt any developer needs all 
   versions from 0.96 to 1.5.  Just a minor annoyance really... please fix the 
   GCS issues asap!


On Tuesday, September 10, 2013 6:14:58 AM UTC-4, Ben Smithers wrote:
>
> Hi,
>
> I've been having some problems writing data to google cloud storage using 
> the python client library (
> https://developers.google.com/appengine/docs/python/googlecloudstorageclient/
> ).
>
> Frequently, the write to cloudstorage will 'hang' indefinitely. The call 
> to open a new file is successful, but the write (1MB in size in this test 
> case) never returns and the file never appears in the bucket. For example, 
> I launch 10 instances of a (backend) module, each of which attempts to 
> write a file. Typically, somewhere between 4 and 9 of these will succeed, 
> with the others hanging after opening. This is the code I am running:
>
> class StartHandler(webapp2.RequestHandler):
>
> GCS_BUCKET="/"
>
> def debugMessage(self, msg):
> logging.debug(msg)
> logservice.flush()
>
> def get(self):
> suffix = str(backends.get_instance())
> filename=self.GCS_BUCKET + "/testwrite" + suffix + ".txt"
> gcs_file = cloudstorage.open(filename, 'w', content_type=
> 'text/plain' )
> self.debugMessage("opened file")
> gcs_file.write("f" * 1024 * 1024 * 1 + '\n')
> self.debugMessage("data written")
> gcs_file.close()
> self.debugMessage("file closed")
>
>
> I have also attached a tarred example of the full application in case it 
> is relevant (to run, you should only need to modify the application name in 
> the two .yaml files and the bucket name in storagetest.py). A few 
> additional things:
>
> 1.) I wondered if this was a problem with simultaneous writes so I had 
> each instance sleep for 30 seconds * its instance number; I observe the 
> same behaviour.
> 2.) I have seen this behaviour on frontend instances, but far far more 
> rarely. I modified the above to run in response to a user request - once 
> out of 60 times the write hung after opening (a Deadline Exceeded Exception 
> was then thrown). 
> 3.) I have experimented with the RetryParams (though according to the 
> documentation, the defaults should be sufficient) but to no avail. I also 
> find it hard to believe this is the issue - I would assume I would be 
> getting a TimeoutError.
>
> Has anyone else observed this behaviour? Does anyone have any suggestions 
> for what I am doing wrong? Or a different approach to try?
>
> Very grateful for any help,
> Ben
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Writes to cloud storage hanging after opening file?

[Doug Anderson]

I realize this is likely a GCS server issue and I don't mean to distact 
from that but I'd also like to point out that the SDK's 
google-api-python-client (which I assume GCS relies upon under the hood) is 
v1.0beta6 from Oct 28, 2011, where the latest release seems to be v1.2 from 
Aug 7, 2013.  I assume the runtime versions on the live servers are up to 
date :)  PKG-INFO snippets below:

--- Latest PKG-INFO snippet ---
Metadata-Version: 1.1
Name: google-api-python-client
Version: 1.2
Summary: Google API Client Library for Python
Classifier: Development Status :: 5 - Production/Stable

--- App Engine SDK 1.8.5 PKG-INFO snippet ---
Metadata-Version: 1.0
Name: google-api-python-client
Version: 1.0beta6
Summary: Google API Client Library for Python
Classifier: Development Status :: 4 - Beta


On Thursday, September 19, 2013 2:03:44 PM UTC-4, Vinny P wrote:
>
> On Thu, Sep 19, 2013 at 7:46 AM, Ben Smithers 
> 
> > wrote:
>
>> It looks like Vinny was correct - writes of a smaller size do not seem to 
>> cause a problem. Specifically, writes from backend instances to datastore, 
>> blobstore and cloud storage of 32KBs all display the hanging behaviour
>>
>
>
> Your experiences parallel mine - backend instances seem to have more 
> difficulty communicating with other Google services compared to frontend 
> instances. I often speculate that there is an additional communications 
> layer within the backends system, or different architectural decisions.
>
>
> On Thu, Sep 19, 2013 at 11:53 AM, Ben Smithers 
> 
> > wrote:
>
>> In light of Doug's comments, I have also confirmed the same behaviour 
>> (success on writing 30KB; some hangs on writing >=32KBs) occurs with the 
>> latest release (r105) of the client library from SVN. I was expecting this, 
>> as it doesn't look like the GCS library is the problem.
>>
>>
>
> +1. I see similar behavior when communicating directly to GCS via the JSON 
> API. 
>
>  
> On Thu, Sep 19, 2013 at 11:50 AM, Ye Yuan >
>  wrote:
>>
>> Yeah from the evidences so far I am also hoping the hangs aren't 
>> originated from the GCS lib.
>>
>>
>
> Ye, I want to emphasize something since you're reading this thread. I 
> believe there are two different issues here: One, backend instance urlfetch 
> to anything (not just GCS) seems to be less stable than frontend instance 
> urlfetch (perhaps there's something chunking requests from the backend?). 
> Second, GCS itself (not the library, but GCS servers) seems to have 
> difficulty with differing chunk sizes. You wrote that GCS has a minimum 
> chunk size of 256KB, but I've flushed chunks much smaller than that 
> reliably and without difficulty. 
>
> So the bottom line here is when you're testing, test from App Engine 
> frontend and backend instances, Compute Engine machines, and from an 
> external-to-Google-networks machine. I'd focus less on the client library. 
>  
>  
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Announcing a credit for App Engine applications with new custom domains

[Doug Anderson]

FWIW... I'd like to add my voice in support of a high priority for this 
capability.  Now that we have SSL... improved domain management is at the 
top of my wish list.  On the email front... I use Mailgun with App Engine 
precisely because I need more flexibility than GAE's native email provides. 
 On the receiving end Mailgun can forward to an HTTP POST handler in your 
GAE app similar to the native GAE email.  I'm not sure if Sendgrid has the 
same HTTP POST capability for incoming mail.   

On Sunday, September 29, 2013 9:42:33 PM UTC-4, Lawrence Mok wrote:
>
> I got exactly the same as yours, that's so inconvenient especially for a 
> company who own 20+ websites for different products.  
>
> On Wednesday, September 4, 2013 3:37:29 PM UTC+8, Sandeep wrote:
>>
>>
>>> Even the use of sub organization is banned now. We don't need new mail 
>>> google apps accounts. We just want to launch it as a sub organization, so 
>>> the site is Up. I wonder even that is not allowed now. 
>>>
>>> And this is the same process I did for many domains of many clients 
>>> earlier wn we have apps for free.
>>>
>>>
>>> 
>>>
>>>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Why GAE is very expensive?

[Doug Anderson]

My biggest gripe about GAE pricing is the $39/month for VIP SSL.  If you 
want a custom domain and aren't yet ready to make the SNI leap then you 
have a $39/month floor just because you want a secure site.  I think GAE 
has us surrounded with enough other pricing boxes that they don't need to 
extract a fee to protect against session hijacking and such.


On Monday, October 7, 2013 7:41:03 AM UTC-4, Claudio Antunes wrote:
>
> I think App Engine is very, very good, but it is very, very expensive.
> Yesterday I was testing my application and I've did a comparison:
> About 600,000 pageviews delivered, I paid US$ 35 to Google.
> I'm using Frontend Instance Class F1 and 50 Max Idle Instances and 4.0s to 
> Min Pending Latency.
> On my current hosting, VPS.NET , I pay US$ 30 daily to 
> have 2 machines with 38.4GHz Dedicated CPU and 6152MB Dedicated RAM to 
> delivery my application. As I use it only  12 hours, I pay only US$ 15.
> So App Engine Is very, but very, but very expensive. And if I enable the 
> Cloud SQL, it will be yet more expensive.
>
> There is anyway to reduce the price?
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Problem using GCS client with the dev server on Windows

[Doug Anderson]

I started getting GCS client errors with 1.8.8 win dev server (code 
previously working).  Upgrading to the latest GCS client code (r127) fixed 
my problem.

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


On Monday, October 7, 2013 10:29:01 AM UTC-4, Francois Masurel wrote:
>
> Hi everybody,
>
> Couldn't succeed in writing a file using the GCS client on the dev server 
> running on my Windows 7 laptop.
>
> I keep getting these kind of errors telling me that my file system can't 
> handle file names with a colon in them :
>
>  directory>\WEB-INF\appengine-generated\encoded_gs_key*:*L2dzL2JibG...
>
> Is it normal? Did I miss something?
>
> Anybody using successfully the GCS client on the dev server running on 
> Windows?
>
> Any help will ge greatly appreciated.
>
> François
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Processing payments using Paypal, python SDK

[Doug Anderson]

My advice would be to use Stripe.com for processing payments.  You'll be 
amazed at how easy it is to get started AND customers don't have to leave 
your site!
(I'm not associated with Stripe in any way... just using it with App Engine 
and can attest to its ease of use)

I may re-add PayPal at some point (in addition to Stripe) but it's a pita 
to deal with the user leaving your site, processing the ipn notifications, 
and then HOPING the user hits the button to return to your site when he's 
finished on PayPal.  With PayPal there's no guarantee the user will return 
to your site (although it's fairly likely).  I've also noticed that the 
initial redirect to PayPal can take a while (for the page to load).  Just 
my experience... I'm sure there are others that really like it.


On Thursday, January 2, 2014 4:52:23 PM UTC-5, Robert Avram wrote:
>
> I'm trying to figure out how to process payments using paypal python sdk 
> and google app engine.
> the following code seems to work, but I can't figure out, based on the 
> SDK, how to handle the exceptions (wrong credit card number etc).
> I would like the customer to be able to see the error. I would appreciate 
> any input! thanks!!!
>
>
> class Buy(generichandler.MainHandler):
>
> def get(self):
>
>api = paypalrestsdk.set_config(
>
>  mode="sandbox",
>
>  client_id="myclientid",
>
>  client_secret="secret")
>
>api.get_token()
>
>paymentDic = {"intent": "sale",
>
>  "payer": {
>
>"payment_method": "credit_card",
>
>"funding_instruments": [{
>
> "credit_card": {
>
>
> "type": "visa",
>
>
> "number": "4417119669820331",
>
>
> "expire_month": "11",
>
>
> "expire_year": "2018",
>
>
> "cvv2": "874",
>
>
> "first_name": "Joe",
>
>
> "last_name": "Shopper",
>
>
> "billing_address": {
>
>   
>"line1": "52 N Main ST",
>
>   
>"city": "Johnstown",
>
>   
>"state": "OH",
>
>   
>"postal_code": "43210",
>
>   
>"country_code": "US" }}}]},
>
>  "transactions": [{
>
>"amount": {
>
>  "total": "1.47",
>
>  "currency": "USD",
>
>  "details":{
>
>"subtotal": 
> "1.41",
>
>"tax": "0.03",
>
>"shipping": 
> "0.03"}},
>
>"description": "This is the 
> payment transaction description." }]}
>
>payment = paypalrestsdk.Payment(paymentDic)
>
>payment.create()
> Enter code here...
>
>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Processing payments using Paypal, python SDK

[Doug Anderson]

Stripe is working hard to expand their international support (add Canada to 
your list along with 8 other countries currently in beta).  But I would 
agree that PayPal has the best international/currency support.  With PayPal 
I can be located in the U.S. and accept payments in a variety of currencies 
(as long as I enable my account to allow it). But to my knowledge with 
PayPal you either have to transfer customers to the PayPal site for a 
portion of the processing OR deal with credit card numbers hitting your 
server and thus having to deal with PCI compliance.  I don't even know if 
PCI compliance is possible with App Engine so that may just leave option #1 
(transfering customers to PayPal for a portion of the processing... a 
perfectly viable option... just less than ideal imo)

On Monday, January 6, 2014 2:41:42 PM UTC-5, Kaan Soral wrote:
>
> If you are inside US you probably didn't notice this, which is good for 
> you, however there is a HUGE barrier around payment services
>
> It's extremely hard to accept payments, you have to be a company at least 
> and procedures after that are blurry
>
> For example you can only use stripe from US/UK/Ireland - as far as I 
> remember
>
> On Saturday, January 4, 2014 9:51:13 PM UTC+2, Doug Anderson wrote:
>>
>> My advice would be to use Stripe.com for processing payments.  You'll be 
>> amazed at how easy it is to get started AND customers don't have to leave 
>> your site!
>> (I'm not associated with Stripe in any way... just using it with App 
>> Engine and can attest to its ease of use)
>>
>> I may re-add PayPal at some point (in addition to Stripe) but it's a pita 
>> to deal with the user leaving your site, processing the ipn notifications, 
>> and then HOPING the user hits the button to return to your site when he's 
>> finished on PayPal.  With PayPal there's no guarantee the user will return 
>> to your site (although it's fairly likely).  I've also noticed that the 
>> initial redirect to PayPal can take a while (for the page to load).  Just 
>> my experience... I'm sure there are others that really like it.
>>
>>
>> On Thursday, January 2, 2014 4:52:23 PM UTC-5, Robert Avram wrote:
>>>
>>> I'm trying to figure out how to process payments using paypal python sdk 
>>> and google app engine.
>>> the following code seems to work, but I can't figure out, based on the 
>>> SDK, how to handle the exceptions (wrong credit card number etc).
>>> I would like the customer to be able to see the error. I would 
>>> appreciate any input! thanks!!!
>>>
>>>
>>> class Buy(generichandler.MainHandler):
>>>
>>> def get(self):
>>>
>>>api = paypalrestsdk.set_config(
>>>
>>>  mode="sandbox",
>>>
>>>  client_id="myclientid",
>>>
>>>  client_secret="secret")
>>>
>>>api.get_token()
>>>
>>>paymentDic = {"intent": "sale",
>>>
>>>  "payer": {
>>>
>>>"payment_method": "credit_card",
>>>
>>>"funding_instruments": [{
>>>
>>> "credit_card": {
>>>
>>>
>>> "type": "visa",
>>>
>>>
>>> "number": "4417119669820331",
>>>
>>>
>>> "expire_month": "11",
>>>
>>>
>>> "expire_year": "2018",
>>>
>>>
>>> "cvv2": "874",
>>>
>>>
>>> "first_name": "Joe",
>>>
>>>
>>> "last_name": "Shopper",
>>>
>>>
>>> "billing_address": {
>&g

Re: [google-appengine] Processing payments using Paypal, python SDK

[Doug Anderson]

The paypal rest api involves receiving credit cards on the server which 
means they are potentially in logs etc (that with App Engine you don't 
control).  This complicates PCI compliance:

*Q: To whom does PCI apply?*
*A: *PCI applies to ALL organizations or merchants, regardless of size or 
number of transactions, that accepts,* transmits* or stores *any cardholder 
data*. Said another way, if any customer of that organization ever pays the 
merchant directly using a credit card or debit card, then the PCI DSS 
requirements apply.

*Q: What is defined as ‘cardholder data’?*
*A: *Cardholder data is any personally identifiable data associated with a 
cardholder. This could be an account number, expiration date, name, 
address, social security number, etc. All personally identifiable 
information associated with the cardholder that is stored, processed, or 
transmitted is also considered cardholder data.

http://www.pcicomplianceguide.org/pcifaqs.php#2

If someone does achieve PCI compliance with the PayPal rest api and App 
Engine please document the process so others can benefit from your 
experience.  I personally believe you're better off redirecting to PayPal 
and back than using PayPal rest.  Enough said on my part... good luck


On Monday, January 6, 2014 3:47:02 PM UTC-5, aschmid wrote:
>
> paypal has a rest api and you don’t need to redirect the customers to 
> paypal. but paypal is a pain to deal with in any case… and customer service 
> is very bad.
> i believe you need to be PCI compliant only if you store the credit card 
> data, not if you just process the api call on server side.
>
> another great service is www.braintreepayments.com which works all over 
> the world.
>
> On Jan 6, 2014, at 3:26 PM, Kaan Soral > 
> wrote:
>
> I was set on Braintree last time I assessed the market, currently deciding 
> on how to incorporate locally, Braintree seems to have the widest coverage 
> for a simplistic/elegant solution similar to Stripe
>
> I think Paypal is a major turn off from many aspects, I would use a layer 
> similar to Paymentwall to handle all-else payments other than credit cards
>
> Spreedly is also extremely promising, it's not a payment gateway but 
> rather a PCI workaround that enables one to switch from one provider to 
> another or use multiple providers etc
>
> (Paypal/Braintree acquisition was alarming, I hope they don't mess 
> braintree too :)
>
> A beautiful reference for anyone who are interested: 
> https://spreedly.com/gateways
>
> On Monday, January 6, 2014 10:16:56 PM UTC+2, Doug Anderson wrote:
>>
>> Stripe is working hard to expand their international support (add Canada 
>> to your list along with 8 other countries currently in beta).  But I would 
>> agree that PayPal has the best international/currency support.  With PayPal 
>> I can be located in the U.S. and accept payments in a variety of currencies 
>> (as long as I enable my account to allow it). But to my knowledge with 
>> PayPal you either have to transfer customers to the PayPal site for a 
>> portion of the processing OR deal with credit card numbers hitting your 
>> server and thus having to deal with PCI compliance.  I don't even know if 
>> PCI compliance is possible with App Engine so that may just leave option #1 
>> (transfering customers to PayPal for a portion of the processing... a 
>> perfectly viable option... just less than ideal imo)
>>
>> On Monday, January 6, 2014 2:41:42 PM UTC-5, Kaan Soral wrote:
>>>
>>> If you are inside US you probably didn't notice this, which is good for 
>>> you, however there is a HUGE barrier around payment services
>>>
>>> It's extremely hard to accept payments, you have to be a company at 
>>> least and procedures after that are blurry
>>>
>>> For example you can only use stripe from US/UK/Ireland - as far as I 
>>> remember
>>>
>>> On Saturday, January 4, 2014 9:51:13 PM UTC+2, Doug Anderson wrote:
>>>>
>>>> My advice would be to use Stripe.com for processing payments.  You'll 
>>>> be amazed at how easy it is to get started AND customers don't have to 
>>>> leave your site!
>>>> (I'm not associated with Stripe in any way... just using it with App 
>>>> Engine and can attest to its ease of use)
>>>>
>>>> I may re-add PayPal at some point (in addition to Stripe) but it's a 
>>>> pita to deal with the user leaving your site, processing the ipn 
>>>> notifications, and then HOPING the user hits the button to return to your 
>>>> site when he's finished on PayPal.  With PayPal there's no guarantee t

[google-appengine] Re: Stuck Trying to apply certificate to Custom Domain

[Doug Anderson]

Here's how I did it:

   1. Login to admin.google.com with your Google Apps user/pwd for the 
   domain
   2. From the Google Apps "Admin Console"
   3. More Controls - Security - Show more - SSL for Custom Domains
   4. You'll then see a form field to enter your App Engine application id 
   and press the button below it
   5. If you're lucky enough for this to work correctly... you can then 
   setup and upload your SSL cert files


On Monday, January 13, 2014 4:04:22 PM UTC-5, Troy Matthews wrote:
>
> My engineering team has created an app and asked me to provide (and 
> install) a SSL cert.  I purchased one for www.domain.com and it covers 
> the naked domain.  I have documentation that explains how to install it, 
> but at step 5 I suddenly deviate from the directions.  My domain only has 
> the new console with no option to the classic view, and thats the 
> documentation I have (classic console).  Can any one share current docs on 
> how to do it?  I already posted with the link to the doc, but it seems to 
> have been caught as spam or something.  Any help is appreciated,
>
> Troy
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Stuck Trying to apply certificate to Custom Domain

[Doug Anderson]

I have been stuck at step #4 on numerous occasions.  For me when it doesn't 
work... after entering the App Engine application ID it takes me to an App 
Engine "start" page to create a new application (under the same Google Apps 
account.  This is not the proper behavior.  What it's supposed to happen 
is... the application ID is looked up and you should be given a chance to 
login to your App Engine account (if it differs from your Google Apps 
account).  You'll then be on a page where you can allocate SNI slots and/or 
choose VIP and upload your certs.  If this is successful then the "SSL for 
Custom Domains" slideout in Google Apps changes (from asking for an 
application ID) to allowing you to edit your SSL config (add more SNI 
slots, add/delete certs, etc)

I have contacted the Google Apps support team a couple times when this 
problem occurred.  For me the problem always resolved within 2-3 days of 
persistent attempts (a few times throughout each day and eventually it 
worked).  The support person I contacted said he would pass the issue along 
to the development team but who knows what impact that will have.  If you 
are also having trouble at stage #4 in Google Apps I suggest you contact 
the Apps support team (via the phone based help).  I believe my issue was 
#03800988 if you want to reference it.

I eagerly await independent App Engine domain management!!!

On Wednesday, January 15, 2014 9:31:17 AM UTC-5, Troy Matthews wrote:
>
> Thanks Doug, I did just that.  When I try to go into the SSL settings and 
> upload, I do not get any options to. just the same add app for custom 
> domain.  Where do I find the setting to upload and choose googles 'monthly 
> fee' for dooling out my cert?  (please and thank you)
>
> Regards,
> Troy
>
> On Tuesday, 14 January 2014 14:43:25 UTC-5, Doug Anderson wrote:
>>
>> Here's how I did it:
>>
>>1. Login to admin.google.com with your Google Apps user/pwd for the 
>>domain
>>2. From the Google Apps "Admin Console"
>>3. More Controls - Security - Show more - SSL for Custom Domains
>>4. You'll then see a form field to enter your App Engine application 
>>id and press the button below it
>>5. If you're lucky enough for this to work correctly... you can then 
>>setup and upload your SSL cert files
>>
>>
>> On Monday, January 13, 2014 4:04:22 PM UTC-5, Troy Matthews wrote:
>>>
>>> My engineering team has created an app and asked me to provide (and 
>>> install) a SSL cert.  I purchased one for www.domain.com and it covers 
>>> the naked domain.  I have documentation that explains how to install it, 
>>> but at step 5 I suddenly deviate from the directions.  My domain only has 
>>> the new console with no option to the classic view, and thats the 
>>> documentation I have (classic console).  Can any one share current docs on 
>>> how to do it?  I already posted with the link to the doc, but it seems to 
>>> have been caught as spam or something.  Any help is appreciated,
>>>
>>> Troy
>>>
>>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Snapchat

[Doug Anderson]

Rafael & Kaan... since you both utilize dynamic image serving, do either of 
you have an issue concerning the size of dynamically served images?  I 
filed the issue below a while ago and it has seemingly been ignored by 
Google.  In short my grievance is that dynamically served images are 
effectively sized with JPEG quality = 100 (or very close to it).  Thus, the 
dynamic images are typically 3x larger than a comparable image scaled 
statically via the the Images service with quality=65 and 2x larger than 
quality=85.  My app saves a large reference image (1440x1080) and I use 
dynamic image serving for a variety of smaller sizes.  For image heavy apps 
the difference really adds up... especially for mobile.  My issue is below 
if you have an interest in this topic (your thoughts/feedback is much 
appreciated):
https://code.google.com/p/googleappengine/issues/detail?id=9979


On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote:
>
> Jim, 
>
> In 2014 a good engineer can create your own cloud infrastructure with 10 
> machines like the ones I suggested.
>
> Again, I am not saying that I don't like appengine. In fact, I love it and 
> that's why I stick with it. 
> I am saying it's over priced to run a service like Snapchat. I don't think 
> there's any argument there. 
>
>
> Kaan,
>
> This is my gift to you: https://gist.github.com/mufumbo/8547036
>
> It extends all of the appengine image features: "=s/-c" and includes the 
> most useful one: "=h"
>
> Depending on appengine's image serving is a limitation, since "vertical 
> cropping" is extremely useful on many elegant websites. 
>
> For example, play around with: http://c1.picmix.net/61757192=s682=h300 or 
> http://c1.picmix.net/61757192=s300=h600
>
> By the way, another way to reduce server costs is to pay the $400 or $200 
> a month in support. 
> That way you get access to discounted instance hours. It decreased our 
> bill a bit and give access to a place to get feedback when appengine is 
> having problems or when you need to tweak your scheduling and performance 
> parameters that you don't have access from XML config.
>
> About three months ago I spent a whole month optimizing my servers to 
> reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for 
> the performance it's delivering.
>
> thanks
> rafa
>
>
> On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral 
> > wrote:
>
>> I think he gets it much more than you give him credit for
>>
>> Hetzner example, as I interpret it, and think about it myself, is about 
>> the price of computing/ram/bandwith, although it's not comparable 1:1, it's 
>> important to know how cheap computing and hosting has become over the 
>> years, especially in this last 5-10 years
>>
>> It was really interesting to hear about your story Rafael, it was the 
>> approximate reason why I started this discussion, to learn and speculate 
>> about major services
>>
>> The 2000$ to 300$ cdn comparison is interesting, however no other service 
>> that I know of matches the extreme capabilities of google images service
>> I use the =s/-c resizing/cropping extensively, that's why I could never 
>> easily replace appengine, or the cdn
>>
>> You seem to have lived my worst case scenario, going out of money and 
>> having to ask others for money.
>>
>> Anyway if you don't mind it would be great to learn more about your 
>> product/story, but I'm guessing it's better to keep things as private as 
>> possible :)
>>
>>
>> On Tuesday, January 21, 2014 9:16:18 PM UTC+2, Jim wrote:
>>>
>>> 1970's?  What on earth about my post made you think of the 1970's?   My 
>>> description of geographically redundant, web based applications?  Please 
>>> indeed.
>>>
>>> The link you provided is for a LAMP hosting service... basically what I 
>>> described in my third scenario about.  That's apples-vs-oranges as compared 
>>> to GAE.  
>>>
>>> I suggest you consult with the Application Architects where you work and 
>>> politely ask them to describe the differences to you.  Clearly nobody here 
>>> is getting through to you and I don't have the time or the inclination.
>>>
>>>
>>>
>>>
>>> On Tuesday, January 21, 2014 12:35:13 AM UTC-6, Rafael Sanches wrote:

 Guys, 

 Please, we're not in 1970 anymore. There is no argue that appengine is 
 the most expensive hosting on earth and possibly the universe.

 My company spend $4000 a month with appengine. We could host the same 
 service with $50 in a more powerful environment:
 http://www.hetzner.de/en/hosting/produktmatrix/
 rootserver-produktmatrix-ex

 With $300 we could make it redundant and more reliable and faster than 
 appengine. 
 A dedicated server is also more reliable, because of appengine infamous 
 "hicupps" due to its scheduling system and insta

Re: [google-appengine] Re: Snapchat

[Doug Anderson]

Yes, the tests I conducted were on the production server.  I'd even be 
content if the resized images used the same default (quality=85) as the 
Images service.  A switch to a more reasonable default would instantly cut 
all dynamically served images to nearly 1/2 the size...  that must be 
significant bandwidth even for Google.  It's either an oversight on 
Google's part OR they deliberately chose not to utilize the extra CPU 
bandwidth required for additional compression (???).

Serving yourself allows additional flexibility (such as in your gist) but 
you don't get the cost benefits of the dynamic image service (no CPU 
charges)

On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote:
>
> Doug,
>
> Does that behaviour also happens in production? Compare prod vs dev. 
>
> That's another reason why I prefered to run my own image serving, I 
> control all the parameters and can also add things like watermarking, 
> vertical cropping and WEBP formatting.  
>
> thanks
> rafa
>
>
> On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson 
> 
> > wrote:
>
>> Rafael & Kaan... since you both utilize dynamic image serving, do either 
>> of you have an issue concerning the size of dynamically served images?  I 
>> filed the issue below a while ago and it has seemingly been ignored by 
>> Google.  In short my grievance is that dynamically served images are 
>> effectively sized with JPEG quality = 100 (or very close to it).  Thus, the 
>> dynamic images are typically 3x larger than a comparable image scaled 
>> statically via the the Images service with quality=65 and 2x larger than 
>> quality=85.  My app saves a large reference image (1440x1080) and I use 
>> dynamic image serving for a variety of smaller sizes.  For image heavy apps 
>> the difference really adds up... especially for mobile.  My issue is below 
>> if you have an interest in this topic (your thoughts/feedback is much 
>> appreciated):
>> https://code.google.com/p/googleappengine/issues/detail?id=9979
>>
>>
>> On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote:
>>
>>> Jim, 
>>>
>>> In 2014 a good engineer can create your own cloud infrastructure with 10 
>>> machines like the ones I suggested.
>>>
>>> Again, I am not saying that I don't like appengine. In fact, I love it 
>>> and that's why I stick with it. 
>>> I am saying it's over priced to run a service like Snapchat. I don't 
>>> think there's any argument there. 
>>>
>>>
>>> Kaan,
>>>
>>> This is my gift to you: https://gist.github.com/mufumbo/8547036
>>>
>>> It extends all of the appengine image features: "=s/-c" and includes the 
>>> most useful one: "=h"
>>>
>>> Depending on appengine's image serving is a limitation, since "vertical 
>>> cropping" is extremely useful on many elegant websites. 
>>>
>>> For example, play around with: http://c1.picmix.net/61757192=s682=h300or 
>>> http://c1.picmix.net/61757192=s300=h600
>>>
>>> By the way, another way to reduce server costs is to pay the $400 or 
>>> $200 a month in support. 
>>> That way you get access to discounted instance hours. It decreased our 
>>> bill a bit and give access to a place to get feedback when appengine is 
>>> having problems or when you need to tweak your scheduling and performance 
>>> parameters that you don't have access from XML config.
>>>
>>> About three months ago I spent a whole month optimizing my servers to 
>>> reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for 
>>> the performance it's delivering.
>>>
>>> thanks
>>> rafa
>>>
>>>
>>> On Tue, Jan 21, 2014 at 11:30 AM, Kaan Soral  wrote:
>>>
>>>> I think he gets it much more than you give him credit for
>>>>
>>>> Hetzner example, as I interpret it, and think about it myself, is about 
>>>> the price of computing/ram/bandwith, although it's not comparable 1:1, 
>>>> it's 
>>>> important to know how cheap computing and hosting has become over the 
>>>> years, especially in this last 5-10 years
>>>>
>>>> It was really interesting to hear about your story Rafael, it was the 
>>>> approximate reason why I started this discussion, to learn and speculate 
>>>> about major services
>>>>
>>>> The 2000$ to 300$ cdn comparison is interesting, ho

Re: [google-appengine] Re: Snapchat

[Doug Anderson]

I think GAE is trying to remain competitive with Amazon Web Services etc... 
and not with CDNs.  App Engine and Google Cloud Storage *is* competitive 
with Amazon Cloud Services EXCEPT those services offer tiered pricing 
(lower prices) for high volume clients... to my knowledge App Engine 
doesn't offer that (at least not publicly advertised).  App Engine isn't 
much of a CDN as far as I can tell (I don't think that's a prime 
objective).  It would be hard to argue against augmenting with an actual 
CDN where appropriate.

Certainly technologies like Docker and OpenStack go a long way toward 
helping a lone wolf build a maintainable stack but I think you'll find that 
if you run that stack on Amazon's cloud (for instance) that GAE pricing 
*is* competitive.  So I would contend that your pricing argument is more of 
a generic Anyone's Cloud vs Custom Hardware argument.  I can certainly save 
a ton of money by storing data on local hard drives vs the cloud but then I 
have to worry about redundancy, drive and fan failures, rebuilds, backups 
etc.  If you want multi-site redundancy and/or need rapid scaling/growth 
costs go up and the cloud starts to look intriguing again.  Each (cloud and 
custom hardware) still has its place imo... 


On Wednesday, January 22, 2014 6:58:42 PM UTC-5, Rafael Sanches wrote:
>
> Hi Doug, 
>
> Just correcting your phrase a little bit: 
> "that must be significant bandwidth even for *YOU*"
>
> We've cut thousands of dollars out of our total bill by serving the images 
> ourselves, through a real cdn. 
>
> Appengine output bandwidth is much more expensive than almost any other 
> cdn out there. 
>
> Again, keeping this thread on topic, my advices only make sense if you 
> have your server bills are in the thousands and are struggling with server 
> costs. 
> If you're an early stage startup with < $100 bill or an overfunded startup 
> or a big corporation, who cares? :)
>
> thanks
> rafa
>
>
> On Wed, Jan 22, 2014 at 3:53 PM, Doug Anderson 
> 
> > wrote:
>
>> Yes, the tests I conducted were on the production server.  I'd even be 
>> content if the resized images used the same default (quality=85) as the 
>> Images service.  A switch to a more reasonable default would instantly cut 
>> all dynamically served images to nearly 1/2 the size...  that must be 
>> significant bandwidth even for Google.  It's either an oversight on 
>> Google's part OR they deliberately chose not to utilize the extra CPU 
>> bandwidth required for additional compression (???).
>>
>> Serving yourself allows additional flexibility (such as in your gist) but 
>> you don't get the cost benefits of the dynamic image service (no CPU 
>> charges)
>>
>>
>> On Wednesday, January 22, 2014 6:09:37 PM UTC-5, Rafael Sanches wrote:
>>
>>> Doug,
>>>
>>> Does that behaviour also happens in production? Compare prod vs dev. 
>>>
>>> That's another reason why I prefered to run my own image serving, I 
>>> control all the parameters and can also add things like watermarking, 
>>> vertical cropping and WEBP formatting.  
>>>
>>> thanks
>>> rafa
>>>
>>>
>>> On Wed, Jan 22, 2014 at 12:57 PM, Doug Anderson wrote:
>>>
>>>> Rafael & Kaan... since you both utilize dynamic image serving, do 
>>>> either of you have an issue concerning the size of dynamically served 
>>>> images?  I filed the issue below a while ago and it has seemingly been 
>>>> ignored by Google.  In short my grievance is that dynamically served 
>>>> images 
>>>> are effectively sized with JPEG quality = 100 (or very close to it).  
>>>> Thus, 
>>>> the dynamic images are typically 3x larger than a comparable image scaled 
>>>> statically via the the Images service with quality=65 and 2x larger than 
>>>> quality=85.  My app saves a large reference image (1440x1080) and I use 
>>>> dynamic image serving for a variety of smaller sizes.  For image heavy 
>>>> apps 
>>>> the difference really adds up... especially for mobile.  My issue is below 
>>>> if you have an interest in this topic (your thoughts/feedback is much 
>>>> appreciated):
>>>> https://code.google.com/p/googleappengine/issues/detail?id=9979
>>>>
>>>>
>>>> On Tuesday, January 21, 2014 2:58:56 PM UTC-5, Rafael Sanches wrote:
>>>>
>>>>> Jim, 
>>>>>
>>>>> In 2014 a good engineer can create your own cloud infrastructure with 
>>>>>

[google-appengine] Re: Jinja 2.7 in Python SDK

[Doug Anderson]

Yep... I filed this in June 2013... one would think it would be a fairly 
straightforward integration... from the outside it feels like Google needs 
another engineer dedicated to GAE Python.  At the time there were other 
pieces of code that were also out of sync with the latest (release) builds 
(Google Cloud Storage client, for example).

I nominate Vinny P for the GAE team!
https://groups.google.com/forum/#!topic/google-appengine/TvunyvSg71g

If you get there Vinny... please push for the return of a roadmap and work 
through the night to get domain management into beta. :)



On Tuesday, February 4, 2014 3:28:24 AM UTC-5, Mohammad Akram wrote:
>
> Are there any plans to update Jinja to 2.7 in Google App Engine?
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Python27 + new dev_appservery.py + debugging

[Doug Anderson]

I've been using PyCharm and am very pleased with it.  I've also used 
JetBrains' WebStorm with node.js projects and was quite pleased with that 
as well.

On Sunday, March 2, 2014 6:49:14 PM UTC-5, Cezary Wagner wrote:
>
> Thanks for hints - it is not helpful.
>
> Discussion is very old and there is not clear conclusion
>
> In my opinion pdb is good for hobbists - placing break points by editing 
> code it is good for 100 lines programs or amateurs - sadomacho :)
>
> It looks that I can not use dart, endpoints because there is no usable 
> debugger for it :)
>
> W dniu niedziela, 2 marca 2014 17:50:44 UTC+1 użytkownik Vinny P napisał:
>>
>> On Sat, Mar 1, 2014 at 9:59 AM, Cezary Wagner 
>>  wrote:
>>
>>> What is the best tools to use dev_appserver.py with breakpoint and 
>>> debugging - what is the best choice.
>>>
>>
>>
>>
>> Hi Cezary,
>>
>> You might want to read this forums discussion here: 
>> https://groups.google.com/forum/#!topic/google-appengine/ep5BWYKpQpU - 
>> there's an interesting discussion on Python debugging with the 
>> dev_appserver.
>>
>> If you're OK with debugging using pdb, you'll want to read this message 
>> in particular: 
>> https://groups.google.com/d/msg/google-appengine/ep5BWYKpQpU/41asdxKhuycJ
>>   
>>  
>> -
>> -Vinny P
>> Technology & Media Advisor
>> Chicago, IL
>>
>> App Engine Code Samples: http://www.learntogoogleit.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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: SSL support

[Doug Anderson]

+1  I've always said SSL on GAE should be free... Google should encourage 
secure connections.  App Engine has us surrounded with enough other toll 
booths that charging for SSL seems completely unnecessary.  It sets the 
baseline cost artificially high for apps that want to use a custom domain 
(I have to believe most apps want security these days with their custom 
domain).

 - Doug

On Friday, March 7, 2014 5:27:31 PM UTC-5, GAEfan wrote:
>
> Just to follow up, 1.75 years later...
>>
>> Year to date, via analytics:
>>
>> 64% of our visitors use Windows
>> 13% of those use XP
>> 31% of those use IE
>>
>> So, that equals 2.6% of our visitors.  4% of our visitors use Android, of 
>> various versions.  I am not sure which version, if any, fixed the SNI 
>> certificate security warning.
>>
>> So, if we used the SNI version, somewhere between 4-6% of our visitors 
>> would not be able to use the SSL.  That is still too high.  We spend too 
>> much to get our visitors, to just send 5% of them away with a bad 
>> experience.
>>
>> We could try redirecting the XP/IE and Android visitors to the secure 
>> appspot domain.  Still not ideal, but a solution.
>>
>> A much better solution would be $99 per year for VIP.
>>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Heartbleed bug?

[Doug Anderson]

Is App Engine's SSL protected from the OpenSSL heartbleed bug?  Since a 
Google Engineer discovered the bug I figure there's a good chance App 
Engine has the patch. ???

http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Heartbleed bug?

[Doug Anderson]

going through ???.appspot.com appears to be clean (not vulnerable to 
heartbleed)... still not sure about custom domains.

On Tuesday, April 8, 2014 10:19:49 AM UTC-4, Doug Anderson wrote:
>
> Is App Engine's SSL protected from the OpenSSL heartbleed bug?  Since a 
> Google Engineer discovered the bug I figure there's a good chance App 
> Engine has the patch. ???
>
> http://heartbleed.com/
> https://www.openssl.org/news/secadv_20140407.txt
>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Anybody interested in a Datastore Manager for GAE?

[Doug Anderson]

If the Admin Console would add support for editing repeated fields I'd be a 
happy camper.  That's the primary reason I have to do custom admin pages. 
 I've also implemented my own bulk upload for HRD... my implementation 
isn't terribly generic though.

On Saturday, June 7, 2014 5:02:35 PM UTC-4, Arvind S wrote:
>
> Why dont we guys have a discussion and start a opensource project for 
>> this. Either a Eclipse Plugin or Chrome Extension? What you guys think ?
>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Datastore Indexes... What's actually supported... My understanding

[Doug Anderson]

Having recently significantly exceeded the 200 index limit... I began 
trying to figure out what GAE actually supports in a desperate attempt to 
get back under the limit.  You'd think the documentation would make this 
clear and maybe it does for bigger brains than mine.  But for me some of 
the older articles and videos just muddy the water and make it unclear 
what's actually real today vs wishful thinking from the past.  The 2011 
Alfred Fuller article does a pretty good job of getting you on the right 
track (https://developers.google.com/appengine/articles/indexselection). 
 The Zigzag merge join that Alfred describes seems to be real and available 
today.  However, there is one limitation that was unclear to me and I 
summarize my understanding as follows:

*GAE can use any combination of indexes to satisfy a query AS LONG AS the 
index contains no outsiders.*

In other words... every field in an index MUST be in the filter expression 
or the index will NOT be used!!!

Stated yet another way... GAE does NOT use more specific indexes to satisfy 
less specific queries.

For example,

Index(Model, field1, field2, fieldSort)
Can NOT be used with:
   SELECT * from Model WHERE field1=val1 ORDER BY fieldSort
   SELECT * from Model WHERE field2=val2 ORDER BY fieldSort
Because the index contains fields that are NOT in the filter expression of 
each query

Given,

Index(Model, field1, field2, fieldSort)
Index(Model, field3, field4, fieldSort)
CAN be used with:
   SELECT * from Model WHERE field1=val1 AND field2=val2  ORDER BY fieldSort
   SELECT * from Model WHERE field3=val3 AND field4=val4  ORDER BY fieldSort
   SELECT * from Model WHERE field1=val1 AND field2=val2 AND field3=val3 
AND field4=val4 ORDER BY fieldSort
Can NOT be used with:
   SELECT * from Model WHERE field1=val1 AND field2=val2 AND field3=val3 
ORDER BY fieldSort
   (or any other combination of 3 fields)
BECAUSE the second index contains field4 (an outsider) which is NOT in the 
filter expression!
(and field3 isn't available in any other index)

Indexing each field individually as Alfred discusses works for any 
combination of fields 1-4 with fieldSort because GAE can
always find a set of indexes that contain no outsiders.  It's really as 
simple as that!

Overlap is OK but outsiders are NOT

Index(Model, field1, field2, field3, fieldSort)
Index(Model, field2, field3, field4, fieldSort)
CAN be used with:
   SELECT * from Model WHERE field1=val1 AND field2=val2 AND field3=val3 
AND field4=val4 ORDER BY fieldSort
The overlap of fields 2,3 in the indexes are OK and there are no outsiders 
in either index
However, now the following queries DON''T WORK because there are outsiders 
in the available indexes:
   SELECT * from Model WHERE field1=val1 AND field2=val2  ORDER BY 
fieldSort  (field3 is an outsider)
   SELECT * from Model WHERE field3=val3 AND field4=val4  ORDER BY 
fieldSort  (field2 is an outsider)

Anyway... I just thought I would share my insight FWIW
I still don't know if I can make the 200 index limit but at least now *I 
think* I understand what works and what doesn't. :)


-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] twittergae - new MIT licensed python code for twitter API access from GAE apps

[Doug Anderson]

twittergae is new MIT licensed python code for interfacing to the twitter 
api from GAE

   - It's relatively lightweight
   - Uses native GAE APIs directly such as urlfetch()
   - Supports sync, async, and ndb-async for any call
   - Supports "update_with_media"... yes multipart upload (embedded photo 
   upload) IS supported!

*Example... send a tweet:*

from twittergae.tweets import Tweets

# Initialize with your twitter credentials
tweets = Tweets(TWITTER_API_KEY,
 TWITTER_API_SECRET_KEY,
 TWITTER_ACCESS_TOKEN,
 TWITTER_ACCESS_SECRET_TOKEN)
tweets.update('Hello Twitterverse from twittergae')

*Developed for:*
https://www.sooshi.com

See example tweets: @sooshicom <https://twitter.com/sooshicom>

*Source code and additional examples on Github:*
https://github.com/claystreet/twittergae

I hope you find it useful!

 - Doug Anderson

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Enable SSL custom domain without Google Apps Account

[Doug Anderson]

You need to go through Apps BUT you don't need to go through Apps 
separately for each domain.  AFAIK you only need to have a separate Google 
Apps account for each domain *if* you need to map the naked domain of each. 
 Otherwise create a single Apps account and at admin.google.com:

1. More Controls -> Domains:
Add each domain as an alias domain

2. More Controls -> App Engine Apps:
Add each GAE app (click the "Add Services" button in the upper 
right-ish of the page)
For each GAE App... "Add new URL" map your domain's urls to the 
appropriate GAE app (ie. http://www.example.com -> myapp-name)

3. More Controls -> Security -> show more -> SSL for Custom Domains:
Upload your SSL certificates, if any
For each certification "Assign URLs" that were previously setup in 
step 2

That's pretty much it... I've done this with 6 alias domains + the primary 
domain (all SSL)

*I wish* there was a way to redirect the naked domains of the 6 alias 
domains but I haven't found a way to do it yet.  I believe a little help 
from Google is required on that one... but I could be missing something!


On Thursday, August 7, 2014 11:29:40 PM UTC-4, Vinny P wrote:
>
> On Thu, Aug 7, 2014 at 9:22 AM, Karl-Heinz Müller  > wrote:
>
>> I want to enable ssl for my custom domains but I don't want to open a 
>> Google Apps account for each domain. How do I proceed?
>>
>
> The short version is: you can't. If you want to set up SSL, you need to go 
> through Apps. See the blue *Important* note on this page: 
> https://developers.google.com/appengine/docs/domain
>
> If you still want SSL without Apps, you can try using Cloudflare to 
> reverse proxy your application: 
> http://blog.cloudflare.com/easiest-ssl-ever-now-included-automatically-w
>  
>   
> -
> -Vinny P
> Technology & Media Consultant
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: HTTPS as a ranking signal

[Doug Anderson]

I hadn't heard about Google Domains until I read it here... it does look 
very promising... I would also consider moving away from GoDaddy.  I found 
this particularly encouraging... (I imagine comparable App Engine support 
for paid Apps is more difficult to implement???)
Support

With Google Domains, you get phone and email support (M-F, 9am to 9pm EST).

On Friday, August 8, 2014 4:00:25 PM UTC-4, Jason Collins wrote:
>
> Re: 
> http://googlewebmastercentral.blogspot.ca/2014/08/https-as-ranking-signal.html
>
> Ok Google, now we most definitely need an API to manage custom domains, 
> mount certificates, and configure HTTPS hosting using an API without a 
> Google account requirement.
>
> Our Cloud Platform hosted products are whitelabelled, meaning people can 
> serve them on their own domain. As the world moves towards HTTPS-always, we 
> need a scaleable way for our customers to upload and configure their SSL 
> certificates fronting our products without our involvement - and without 
> requiring our customers to use a Google account.
>
> That is, we would like APIs that we can build our own user interfaces over 
> top to help our users through this typically frustrating setup experience.
>
> BTW, free SNI-based HTTPS termination was a huge step along the way 
> towards this vision - thanks for that!
>
> Thanks,
> j
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: HTTPS as a ranking signal

[Doug Anderson]

I wanted to share my recent partial success with naked domains... with the 
new cloud console "Custom Domains" you can map your naked non-SSL domain to 
your app.  After doing that... I detect the naked domain as part of my 
'require SSL' logic in the App and redirect to https://www.mydomain.com. 
 So now if someone types "mydomain.com" or "mydomain.com/anypath" in their 
browser it redirects to "https://www.mydomain.com/anypath";.  So the cloud 
console helps plug a hole left by the Google Apps alias domains.  The only 
thing I can't do now is map my SSL naked domain to my app but that is 
likely solvable with a wildcard SSL certificate (that I'm too cheap to pay 
for).


On Friday, August 8, 2014 4:00:25 PM UTC-4, Jason Collins wrote:
>
> Re: 
> http://googlewebmastercentral.blogspot.ca/2014/08/https-as-ranking-signal.html
>
> Ok Google, now we most definitely need an API to manage custom domains, 
> mount certificates, and configure HTTPS hosting using an API without a 
> Google account requirement.
>
> Our Cloud Platform hosted products are whitelabelled, meaning people can 
> serve them on their own domain. As the world moves towards HTTPS-always, we 
> need a scaleable way for our customers to upload and configure their SSL 
> certificates fronting our products without our involvement - and without 
> requiring our customers to use a Google account.
>
> That is, we would like APIs that we can build our own user interfaces over 
> top to help our users through this typically frustrating setup experience.
>
> BTW, free SNI-based HTTPS termination was a huge step along the way 
> towards this vision - thanks for that!
>
> Thanks,
> j
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: GAE SDK Release announcements ???

[Doug Anderson]

I've been wondering for a while if the 2.0.0 release would be anything 
particularly special or just another incremental bump from 1.9.9? :)  I'm 
guessing the later since all seems relatively normal on the eve of the bump.

+1 to announcing here though

On Tuesday, August 19, 2014 1:34:18 PM UTC-4, PK wrote:
>
> It used to be that new GAE SDK releases would be announced in this group. 
> Lately, I have not seen any announcements. The last announcement I can find 
> is 1.9.3 and the downloads page and dashboard show 1.9.9.
>
> So my question is are the GAE SDK releases announced somewhere else? I 
> think the pre-release announcements was a good practice too although  I 
> understand that the last few releases are very minor on the SDK side.
>
> Thanks,
> PK
> http://www.gae123.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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] store images in datastore using php

[Doug Anderson]

As Vinny and others have said... use Google Cloud Storage and dynamic image 
serving.

BUT please also star this issue: 
https://code.google.com/p/googleappengine/issues/detail?id=9979

To make a long story short... when the dynamic image serving service 
resizes a jpeg image it effectively uses a quality parameter of 100.  So, 
if you're like me and save a single large-ish image and rely on dynamic 
image serving to deliver thumbnails and intermediate sizes... you can end 
up with 2x-3x larger images than necessary.  For example, I save images in 
GCS at 1440x1080.  An example image served dynamically with GAE image 
serving at 320x240 is 34k in size.   Taking that same 1440x1080 example 
image and creating a 320x240 jpeg with quality=85 results in an 18k image 
and at quality=65 results in an 11k image.  Visually, the quality is still 
decent even at q=65.

What I'd like to see is the dynamic image serving default to quality=85... 
that is a pretty standard setting.  Ideally (as the issue mentions) an 
additional quality parameter could be tacked onto the url (but that is 
gravy).  A simple switch to a default of 85 would save a lot of bandwidth 
on image heavy apps.


On Monday, August 18, 2014 6:09:05 PM UTC-4, Vinny P wrote:
>
> On Mon, Aug 18, 2014 at 3:00 PM, Rohith D Vallam  > wrote:
>
>> thanks a lot for your reply. Actually i am a novice to GAE. I could not 
>> understand your reply very clearly. Is there a difference between 
>> "DataStore" and "Cloud DataStore " ?  
>>
>  
>  
> What Barry is saying is that there's a difference between the Datastore 
> and Google Cloud Storage. The articles you linked to discuss storing images 
> in the datastore, but it is much better to store, process, and serve images 
> using Cloud Storage as the backend. 
>  
> Here is how to upload an image (with code examples): 
> https://developers.google.com/appengine/docs/php/googlestorage/user_upload
> Here is how to serve the uploaded images: 
> https://developers.google.com/appengine/docs/php/googlestorage/images
>  
> The datastore is not currently available for PHP-based applications, so if 
> you need to store additional data such as users, address, etc (as you 
> stated in your original post) you'll need to use Cloud SQL: 
> https://developers.google.com/appengine/docs/php/cloud-sql/
>
>   
>  -
>  -Vinny P
>  Technology & Media Consultant
>  Chicago, IL
>  
>  App Engine Code Samples: http://www.learntogoogleit.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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Naked domain doesn't work with Godaddy and my application

[Doug Anderson]

I assume you fixed it or the DNS had time to propagate because your naked 
domain works for me.

On Monday, August 25, 2014 10:24:14 AM UTC-4, cahit coşkun wrote:
>
> Hi,
> I tried to configure a naked domain for my application with the 
> instructions from 
> https://developers.google.com/appengine/kb/general#naked_domain but it 
> doesn't work. I added 4 A and  records to my domain name in Godaddy as 
> shown in the documentation. Domain works with "www" subdomain and the 
> address is "www.kombiteknisyen.com" but "kombiteknisyen.com" doesn't work.
> These are my configurations
>
>
> 
>
>
> 
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: My recent support experience (ongoing) and things Google must improve

[Doug Anderson]

My recommendation would be one of the following for bronze customers:

   1. Give bronze customers 1 (non-billing) support ticket per month
   2. Give bronze customers N tickets per year
   3. Give bronze customers 1 ticket for every X dollars spent on services 
   (1 ticket per $150 spent on services, for example... not per month but 
   spent cumulatively).  This way you're "earning" tickets based on spend rate

It's really an odd type of service where you are paying for services but 
have limited ability to receive support.  I think it sort of evolved from 
the old days when everything was free... then they introduced billing 
without a comparable support system.  Eventually somebody came up with this 
pay for support model which I am just fundamentally against on principle... 
if you charge for a service you should stand-up and support the service. 
 It just seems like the App Engine is completely free mentality still 
lingers a bit too much... 

FYI... I am also only a bronze customer (paying for services but not 
$150/mo for special support) and had a recent billing inquiry.  The initial 
response took a while for me too (6 days sounds about right), however, once 
I received a reply I couldn't have been happier with the support I 
received.  AFAIK I could reply to all the emails I received and I did reply 
2-3 times.  Once the Google support team was engaged (after initial 
contact) the replies came back quickly every time.  My support person took 
a genuine interest in my case and helped resolved my issue.  Once you get a 
hold of them, the Cloud Services support team is really good (from my 
experience).


On Thursday, August 28, 2014 7:48:37 AM UTC-4, Kaan Soral wrote:
>
> I've recently created a ticket through the free billing support (
> https://support.google.com/code/contact/cloud_platform_billing?rd=1)
>
> After ~6 days, I got a reply (of course I supressed the issue in 6 days, 6 
> days is a long long time, but it really doesn't matter) - the issue was a 
> minutely quota increase request
>
> The assigned representative was pretty excellent, contacted the 
> engineering team, and updated me at each step, *however*, all of the 
> emails are sent from noreply emails, and there is no way to reply back to 
> the representative, he is updating me on the issue, asking questions 
> related to the issue, however I can't reply to him, feels pretty bad
>
> In the meantime someone from engineering requested some information too, 
> this time from a repliable email, I think I might get a quota increment 
> after all (It has been 2 weeks from my request, I'm guessing I might get a 
> final reply soon, all my previous/ancient attempts had failed)
>
> My suggestion would be to implement a decent communication interface for 
> Bronze support too (I haven't seen the Silver/Gold interface)
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: do a simple search when ran out of complex search quota

[Doug Anderson]

Just curious... do you have billing enabled?  The free quota limits are 
pretty low last I checked (100/day complex, 1000/day simple).  I'm pretty 
sure there are no query limits if billing is enabled... I'm working on more 
heavily adopting the search API  and I'm interested in any issues people 
are having with it (quota limits, high costs, etc).

On Wednesday, April 30, 2014 5:03:58 AM UTC-4, Jnnese C wrote:
>
>
> Hi,
> I ran out of complex search quota, and i still have simple search quota.
> But if i do a simple search , it still throws an OverQuotaException.
>
> Is it a normal situation? does anyone have the same issue?
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Google Billing + Renewed Credit Card = Cancer

[Doug Anderson]

My CC renewed in June (same card #, different CVC, updated expiration, 
etc.)... I received the following email from Google Billing and all worked 
out perfectly (I was actually quite impressed with the level of 
integration):

We're updating your bank account details.

 

Hello from Google, 

We'll be updating your Credit or debit card according to instructions from 
your bank. here are the changes they requested: 

Your bank or credit institution has extended the expiration date on your 
account. 

You don't need to do anything for these changes to take effect, but if you 
have any questions about them, please contact your bank. 

If you'd like to review your direct debit details, follow these steps:
   
   1. Sign in to the Google Developers Console and select the "Billing" tab 
   in the left-hand navigation menu..
   2. Then click on "Billing settings".


See you online, 
The Google Billing Team

On Tuesday, September 2, 2014 6:30:29 AM UTC-4, Kaan Soral wrote:
>
> *I really hate to use this group for google-related rant that is not 
> directly related to technical appengine matters, but here it goes*
>
> Recently my main credit card got renewed keeping the credit card number, 
> with an extended expiry and a new CVV
>
> I've renewed the records of many services, many of which are much smaller 
> than google
>
> Google billing in general doesn't let you delete primary credit cards, 
> doesn't let you edit the CVV, doesn't let you enter a new credit card with 
> the same credit card number
>
> As you might have deducted, it's impossible for me to update my credit 
> card records (Unless I utilize a placeholder-swap method, entering a 
> placeholder card as primary, deleting the old one, entering the updated 
> one, deleting the placeholder, repeating this 20 times, there is always the 
> fear that the billing will charge this placeholder card and make things 
> much much more complex for me)
>
> The other issue is the amount of billing records google billing keeps, 
> I've received 20+ emails from google, from enterprise/cloud/appengine for 
> each app, it's exhilarating, I currently gave up, probably will try to deal 
> with the vital apps soon
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: "One senses GAE is just not a major priority for Google"

[Doug Anderson]

I've certainly felt that App Engine hasn't been a significant priority for 
Google for quite some time.  Legitimate bug reports can go unacknowledged 
for years.  The velocity of change has been largely centered around 
increased language support rather than significant service expansion and/or 
bug fixes.  It comes across as "We've invested in this GAE ecosystem.  What 
can we do to get more people to adopt it before we invest too much more?" 
 So rather than expand/enhance the services themselves they focused on 
additional language bindings.  Now, it feels like they've realized even the 
additional language bindings weren't enough.

The recent announcements around the Google Cloud Platform Live event make 
it pretty clear that Google realizes it can't tackle the cloud alone.  With 
Kubernetes/Google Container Engine, bitnami, and Managed VMs for App Engine 
it's clear Google is building around Google Compute Engine in much the same 
way Amazon built AWS around EC2.  I'm sure at some point all App Engine 
instances will be migrated to Compute Engine.  Other than VMs for App 
Engine going beta I don't think there were any GAE service expansion 
announcements at the Live event.  So this new, open, cooperate, run 
anything approach is the shiny new toy in the Google Cloud group (I don't 
see this as a bad thing... just more evidence that legacy GAE core services 
are NOT a priority).

There's A LOT to like about GAE... I REALLY like the dynamic image serving 
service, IP geo-location with every request, ndb w/ integrated auto 
memcaching, and NOT having to worry about OS and web server 
configuration!!!  GAE's ease of use is an area where Google actually has an 
advantage over AWS.  But as a developer there's an uneasy feeling about 
adopting a proprietary platform like GAE when you see legitimate bugs 
remaining stale for years at a time and the rate of service 
expansion/enhancement seems almost stagnate.  All the new announcements 
seem to be pointing somewhere beyond legacy GAE which just reinforces the 
uneasy feeling.

 - Doug


On Tuesday, October 28, 2014 5:11:15 PM UTC-4, Emanuele Ziglioli wrote:
>
> I would find hard to disagree:
>
> *IBM, Google, and Oracle are all equally at pains to deliver a message 
>> that makes them uniquely attractive. In this regard, Google's inability to 
>> recover from the botched roll-out of Google App Engine (GAE) will surely go 
>> down as one of the oddest business cases. It launched the product with 
>> great fanfare. But developers who flocked to it initially found a difficult 
>> platform that supported only a subset of Java and a very old version of 
>> Python. Moreover, the interfaces to the proprietary database were poorly 
>> thought out, so that almost everything in GAE required platform-specific 
>> code-arounds. While GAE has improved in a limited sense since then, Google 
>> has not done what Microsoft did — revamp the product from top to bottom to 
>> make it easy to use. Nor has it leveraged its natural connection to 
>> developers. One senses GAE is just not a major priority for Google.*
>
>
> http://www.drdobbs.com/cloud/whose-cloud-will-you-use/240169229
>
>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: "One senses GAE is just not a major priority for Google"

[Doug Anderson]

I don't think there's any reason to migrate existing apps unless App Engine 
no longer satisfies your requirements.  I don't see App Engine going 
away... you just need to set your expectations of the platform accordingly 
(don't expect bugs to get resolved unless you have a paid support plan, 
don't expect earth shattering new services/features, etc).

On Wednesday, November 5, 2014 3:31:40 PM UTC-5, Emanuele Ziglioli wrote:
>
> Thank you everyone for your insights, very interesting.
>
> What do you guys think it's the way forward?
> Are you going to migrate your GAE apps to to Managed VMs, with Docker and 
> the gcs command line tools?
>
> Also, is the Datastore still a valid option? 
> I wish BigQuery just worked natively with it...
>
> Thanks 
> Emanuele
>
>

-- 
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-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: "One senses GAE is just not a major priority for Google"

[Doug Anderson]

+1 nice to hear from Dan... very encouraging indeed!!!
+1 to PKs comments as well...

Hopefully Dan's improvement list includes better Datastore admin... 
especially the ability to edit repeated fields!  I have to write custom 
admin code for every repeated field I may need to edit.  The strategic use 
of repeated fields is key to success with the GAE datastore so it's not 
like they are some obscure back seat feature.

I really like Dan's comments about SSDs... the write time on the datastore 
is terrible compared to AWS Dynamo (all SSD with single digit ms writes) 
BUT the datastore has better transaction support and is arguably a better 
general purpose datastore (includes zigzag merge-join queries etc).

Managed VMs via Docker containers gets a big thumbs up from me as a GAE gap 
filler!  Looks very promising!

 - Doug


On Tuesday, November 11, 2014 12:25:24 PM UTC-5, PK wrote:
>
> Hi Dan,
>
> thanks for taking the time. We have not heard from anybody from Google in 
> this forum for many months so your reassuring communication is very 
> welcome. 
>
>  I list below some of the reasons that might explain why some of us who 
> have been following GAE for a long time have been skeptical about Google’s 
> commitment and jump to conclusion when articles like this appears in the 
> press.
>
> 1. There are still 3,000 issues open in the tracker 
> .
>  
> Although many of them are irrelevant enhancements others are critical. For 
> instance, 
> ---we never expected that 5 years later would be still unable to send 
> 8-bit e-mail through the platform (issue 2383 
> ) or 
> —in the critical area of security we would have to deal with a Users API 
> stuck in the 2009 reality and crashes in certain important use cases 
> (issues 9045 
>  and 8916 
> )  or
> --- that it would still be so difficult to create an SSL app (issue 8528 
> ). 
> 2. Now what makes this more frustrating is that bugs have been aging for 
> way too long. For instance, issue 2383 was filed in 2009, it was accepted 
> in 2012 and at the end of 2014 it is still open.
> 3. Google used to communicate a roadmap here 
> . 
> This was great for our planning. At some point the roadmap disappeared, 
> again without communication. Furthermore, until a few months ago new 
> releases (and pre-releases) were announced in this forum. Then suddenly the 
> announcements and every Googler disappeared without warning. StackOverflow 
> is a great Q&A forum but is not a discussion or announcement forum. 
> 4. Finally, last but not least the enthusiasm on Google’s part does not 
> come across. I have been following GAE and developing since almost day one. 
> The early days the developers were out here and in the irc chatrooms all 
> the time. Input from customers was actively sought. Now we do not see 
> anybody from your engineering/PM team here in the trenches.
>
> Knowing the alternatives, I remain very enthusiastic about PaaS in general 
> and GAE in particular. I acknowledge that the GAE stability is very good, 
> Google’s innovations in the hybrid IaaS/PaaS cloud is significant and that 
> recently I have seen more activity in the issues tracker. For instance, I 
> was impressed how proactive you were when I filed 11396 or regression 
> 10503. 
>
> I remain optimistic that the GAE stability will stay where it is but also 
> that the Google investment reflected in *faster feature velocity* will 
> increase, and the *open communication* will return.
>
> Best,
> PK
> http://www.gae123.com
>
>
> On November 10, 2014 at 8:09:09 PM, Daniel Sturman (stu...@google.com 
> ) wrote:
>
>   Hey fellow App Engine users,
>
>  There is some great conversation in this thread. I’ll try to address some 
> of the key points being discussed.
>
>  Regarding the discussion group; our apologies for the delayed response. 
> Most of our customer questions now come on  Stack Overflow 
> , so we’ve 
> been monitoring it more actively than this forum. We’ll be watching this 
> forum more closely too from now on.
>
>  Regarding the larger topic of Google’s investment in App Engine: App 
> Engine is a critical part of our cloud story, and will continue to be. 
> We’re investing heavily in it. In the most recent months this investment 
> has had two major prongs - stability improvements and new efforts to create 
> a more flexible model within App Engine.
>
>  First, stability improvements. App Engine has grown and so has the size 
> and sophistication of

[google-appengine] Re: Blobstore file upload with other form values

[Doug Anderson]

FWIW I'm facing the same problem and I'm reasonably certain the issue is 
simply a limitation of the BlobstoreUploadHandler.  The handler stores 
uploaded blobs perfectly fine and gives your handler the BlobInfo for each 
blob BUT it seems to discard any non file (type='file') form fields.  So if 
you want to upload a text description along with a photo you're out of luck 
(using the blobstore).  I don't actually want the text description stored in 
the blobstore but I'd like it passed to the handler so I can store it in the 
datastore.

PLEASE FIX this blobstore upload issue... please make other (non file) form 
fields available to BlobstoreUploadHandler derived classes.  Thank you!

On a separate note I'm really looking forward to the programmatic access to 
the blobstore that I see listed on the roadmap!

-- 
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-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Blobstore file upload with other form values

[Doug Anderson]

I have to retract my previous post... this does appear to be working
for me.  I can use "self.request.get('description')" to retrieve the
text description form field.  My previous problem was that
name='descripton' was spelled wrong in my html form (missing the last
'i')... doh!

I think your issue is that you lose your "self.response.out.write(N)"
content when you redirect via "return self.redirect('/')"... that
response body content won't survive the redirect (the redirect will
provide its own content).  If you need to return the submitted N and S
content then perhaps you could redirect to a URL that takes the 'a'
object key as a parameter "self.redirect('/' +
urllib.quote(a.key()))".  Of course you'd have to setup your handler
to accept the parameter... but then you could re-retrieve 'a' object
in the handler via a datastore get such as "a = db.get(a_key)"...
assuming 'a_key' is the name of the parameter.


On Feb 13, 1:54 am, theone  wrote:
> I think you are right about BlobstoreUploadHandler limitations. When I
> tried something like:
> class X(db.Model):
>     N = db.StringProperty()
>     S = db.StringProperty()
>     F = blobstore.BlobReferenceProperty()
>
> class Upload(blobstore_handlers.BlobstoreUploadHandler):
>     def post(self):
>         upload_files = self.get_uploads('file')
>         a=upload_files[0]
>         N = self.request.get('name')
>         S = self.request.get('sname')
>         if S:
>             m=N + S
>         else:
>             m=S + N
>         self.response.out.write(N)
>         self.response.out.write(S)
>         a=X(N=m, S=S, F=a)
>         a.put()
>         return self.redirect('/')
>
> It worked partly. I mean I put my model to datastore and file to
> blobstore. However, it does not writes the thing like:
> self.response.out.write(N). What I understand here we cannot use
> everything in BlobstoreUploadHandler.
>
> Also if you request the form fields, it does not work.

-- 
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-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.