Re: [google-appengine] Re: One senses GAE is just not a major priority for Google
+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 https://code.google.com/p/googleappengine/issues/list?can=2q=colspec=ID+Type+Component+Status+Stars+Summary+Language+Priority+Owner+Logcells=tiles. 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 https://code.google.com/p/googleappengine/issues/detail?id=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 https://code.google.com/p/googleappengine/issues/detail?id=9045 and 8916 https://code.google.com/p/googleappengine/issues/detail?id=8916) or --- that it would still be so difficult to create an SSL app (issue 8528 https://code.google.com/p/googleappengine/issues/detail?id=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 http://code.google.com/appengine/docs/features.html#Roadmap_Features. 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 QA 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 javascript:) 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 http://stackoverflow.com/questions/tagged/google-app-engine, 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 the workloads that relied on it (thanks to developers like you). We realized it was
[google-appengine] Re: One senses GAE is just not a major priority for Google
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
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.
[google-appengine] Re: Google Billing + Renewed Credit Card = Cancer
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: My recent support experience (ongoing) and things Google must improve
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
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: Naked domain doesn't work with Godaddy and my application
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 https://lh5.googleusercontent.com/-hfzSvykjRlE/U_tGxax0_OI/B24/DbYvzJjUNP0/s1600/engine.jpg https://lh3.googleusercontent.com/-lt4m6ft3ioE/U_tG7oFtEtI/B3A/kU1io0PD-Yc/s1600/godaddy.jpg -- 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
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 rohi...@gmail.com javascript: 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: GAE SDK Release announcements ???
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.
[google-appengine] Re: HTTPS as a ranking signal
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
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.
Re: [google-appengine] Enable SSL custom domain without Google Apps Account
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 karl...@gmail.com javascript: 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] twittergae - new MIT licensed python code for twitter API access from GAE apps
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.
[google-appengine] Datastore Indexes... What's actually supported... My understanding
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] Re: Anybody interested in a Datastore Manager for GAE?
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] Heartbleed bug?
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?
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.
Re: [google-appengine] Re: SSL support
+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.
Re: [google-appengine] Python27 + new dev_appservery.py + debugging
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 cezary...@gmail.com 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.
[google-appengine] Re: Jinja 2.7 in Python SDK
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] Re: Snapchat
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 kaan...@gmail.comjavascript: 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-exhttp://www.google.com/url?q=http%3A%2F%2Fwww.hetzner.de%2Fen%2Fhosting%2Fproduktmatrix%2Frootserver-produktmatrix-exsa=Dsntz=1usg=AFQjCNHB4pohCO2ZKGcxoTG5sY0nc6pvDw 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 instance boot time. In one of my services I rent a rack with 20 spaces and it's filled with only 10 severs. It means I can scale my servers with 10 more. That configuration costs $1000.
Re: [google-appengine] Re: Snapchat
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 do...@claystreet.comjavascript: 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 kaan...@gmail.com 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
Re: [google-appengine] Re: Snapchat
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 do...@claystreet.comjavascript: 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 do...@claystreet.comwrote: 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
[google-appengine] Re: Stuck Trying to apply certificate to Custom Domain
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.
[google-appengine] Re: Stuck Trying to apply certificate to Custom Domain
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] Processing payments using Paypal, python SDK
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 kaan...@gmail.com javascript: 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 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
[google-appengine] Re: Processing payments using Paypal, python SDK
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: { 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
[google-appengine] Re: Processing payments using Paypal, python SDK
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: Problem using GCS client with the dev server on Windows
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 : path to War maven target 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: Why GAE is very expensive?
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 http://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: Announcing a credit for App Engine applications with new custom domains
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. https://lh4.googleusercontent.com/-FX2ckAoALFk/UibiQJRV3VI/XzI/P3tLLHp8k9w/s1600/domainSettings.png -- 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?
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?
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 smithe...@googlemail.comjavascript: 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 smithe...@googlemail.comjavascript: 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 y...@google.com javascript: 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] Request to add jinja v2.7 to python sdk and live runtime environment
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: 1.8.1 Pre-release SDKs Available.
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/listhttp://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
[google-appengine] Re: 1.8.1 Pre-release SDKs Available.
... 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/listhttp://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.getoption() is called, a mock value is returned, calls to setoption() 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 emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email
[google-appengine] Re: 1.8.1 Pre-release SDKs Available.
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.
Re: [google-appengine] Re: 1.8.1 Pre-release SDKs Available.
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 Libraryhttps://code.google.com/p/appengine-gcs-client/to Preview in the 1.8.1 release. Unlike Experimental features, Preview features are guaranteed to move to General Availability (GA). We encourage developers to start moving over to the new Cloud Storage Client Library as soon as possible. Information on getting started can be found at the open source project linked below. https://code.google.com/p/appengine-gcs-client/ Cheers, -- Chris Ramsdale Product Manager, Google App Engine On Tue, Jun 4, 2013 at 6:34 PM, Jason Galea ja...@lecstor.comjavascript: 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 pand...@gmail.comjavascript: 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/functionshttps://developers.google.com/appengine/docs/python/googlestorage/functionsand https://developers.google.**com/appengine/docs/java/** googlestorage/overviewhttps://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 posthttps://groups.google.com/forum/?fromgroups#!searchin/google-appengine/google$20cloud$20storage$20library/google-appengine/vXKiUHvPHRs/7ia8d_xO8KYJon 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, Google's push for use of Cloud Storage, and the lack of a blobstore API in the PHP runtime should we be ready for you guys to announce the deprecation of the blobstore entirely? I hope not. I like the blobstore and how it is nicely and automatically isolated to a single app.
[google-appengine] Re: 1.8.1 Pre-release SDKs Available.
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/listhttp://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.getoption() is
[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?
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: Taskqueue execution latency up by 1000x
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: Sending emails from gae using mailgun
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 m...@samples.mailgun.org javascript: , to: [t...@gmail.com javascript:, to...@outlook.comjavascript:], # 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: SSL support
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.
Re: [google-appengine] Re: Announcing SSL for Custom Domains Trusted Tester Program
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 jimgill...@gmail.com wrote: How about some status? On Mar 28, 3:34 pm, Kaan Soral kaanso...@gmail.com 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 and as such we would advise against using this on production applications. If you have any queries, please email google-appengine-ssl- feedb...@google.com. Cheers, Cayden Meyer Product Manager, Google App Engine Blogger:http://googleappengine.blogspot.com Reddit:http://www.reddit.com/r/appengine Twitter:http://twitter.com/app_engine -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-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
Re: [google-appengine] Re: Announcing SSL for Custom Domains Trusted Tester Program
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
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: Blobstore file upload with other form values
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
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 maliha...@gmail.com 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.