到目前为至，你认为Google App Engine 的最大不足是什么？

没有http长连接？

channel不是用来实现长连接的吗？

会被gfw关照

墙！

Qiang !

讨论下纯粹的技术有那么难么？

我们都知道中国政府部署了一些技术挡掉了 *.appspot.com，但是这个和 GAE 平台的技术发展其实没有任何关系。我们讨论点技术吧。

@Livid 请教国内如何使用GAE（不翻的情况下）

@Livid 是反向还是别的什么

撇开墙的因素，即使在国外gae也不是个流行的解决方案。
其实我感觉gae对中小企业绝对是个福音，基本上只要投资个域名就完成了建站过程。gae没有理想中发展起来，我认为更多是云计算没有得到更广泛的接受，it公司从利润方面考虑也不会推荐客户去选择gae。

技术方面
1. 不方便操作文件，比如设计一套支持模版的系统，怎么让用户自定义的模版传上去就是个问题，我不觉得把文件存在data source里是个好的办法，google storage发布了，可能能缓解这个问题吧，但这始终不如操作本地文件方便快捷。
2. 不支持大众化的开发语言，刚开始支持python，后来多了java，现在又多了个go，这都不如直接加入php影响大，google的架构似乎不太可能会加入php

本地导入1万条以上数据后，整个GAE的demo会变的很占资源。

Datastore 本身的效率问题。 filter IN sucks ， 效率极差，还不如循环query，然后在程序里重组query结果。

其它的都还不错。

如楼上所说，Datastore做的太烂了。

没有文件读写。。。

太好了，至少个人觉得对大多数应用足够。有时候不是平台局限，而是思维局限，用它做它能做的事。

@ccdjh 本地的开发环境和实际的GAE完全不同，
本地环境类似于“虚拟机”

我很希望它对 XMPP 的支持能够更全面点，比如能把 Google Apps 的域名用作 JID，自定义头像，默认状态等等，而不是使用它的域名，同样的还有 mail 也是，收件账号和发件账号希望可以自定义。

高效率的分页很痛苦。

One-to-Many relationship 需要仔细设计。

@iandyh 真的没有必要分页。很少有机会去一页一页的翻。

我更觉得全文搜索更有必要。

为什么没人提完全不可靠的数据读写，以及任何操作？
写入数据很可能timeout，读取也是。就连query方法获取当前位置也会timeout
xmpp发消息探测状态会莫名奇妙的xmpp.Error
还有完全没有文档介绍的各种ApplicationError，以及urlfetch不抛出timeout，直接全局DeadlineExceed了
另外各种每秒5次的操作限制（读取写入Datastore，urlfetch等等），就连taskqueue也会因为莫名的timeout而存储失败，也做不了跨请求的调度这些很容易超标的api。
总之非常的不稳定，不是花钱能解决问题的。

@lepture 做社区类型的，还是需要吧。尤其是一个贴有很多回复的，过了 1000 个，用 range 这个方法就不行了，除非用每一个回复的 id 做 primary key。

嗯，全文搜索，赞同。我也在为这个伤脑筋。。

@ayanamist 大量的写入可以用 Task Queue 来做。如果是 back-end 需求，现在也有新的服务提供了。 我觉得 Google 提供的 Transaction 已经很棒，ACID 都满足了。对于一个分布式的架构，能做到这点很牛逼。

你真的有 entity 达到每次 5 秒的写入频率？如果你的 app 一天使用 10 个小时，那也是而是万 PV 每天啊。即便有，Google 也有提供文档告之如何避免 Data contention 吧。

@iandyh 我是做GTalk机器人的，瞬发能达到每秒5次甚至更多。你真的应用过Task Queue吗？由于基于Datastore，所以一样会出现Timeout导致Task存储失败。Google的那个文档是扯淡的，潜在的鼓励你花钱去买他的服务。我已经用了一些很dirty的hack了。
Transaction也不靠谱的，在高写入情况下一样会有各种问题。我后台那里长长的各种诡异的Error就不截图了。你可以去看看我写的TwiTalkerPlus的代码，很多恶心的实现都是被逼的

@nttdocomo 他的意思是urlfetch不支持keepalive吧

@ayanamist 我现在在用 Task Queue，做后台计算。

本身 Transaction 就无法应对高写入啊，你的例子需要用到 http://code.google.com/appengine/articles/scaling/contention.html 这篇文章用到的东西。

django版本太低了都懒得修改

@ayanamist 同感同感，urlfetch的各种ApplicationError就已经很郁闷了，所以我搞goagent就没用Datastore。

@phus 歪个楼，多谢你的 goagent，很好用。

DataStore 的查询性能

SDK不支持python2.7....

Fedora 15都换到 Python3.*了... 本来SDK在2.7都基本没法用... 到3.*根本没法想...

愁..

数据备份，导入导出！！！！！！！！！！！！！

我现在还不知道怎么备份～～～没有相应的好用的工具，自己写不来！！！

我遇到的问题主要在文件上传方面（主要是图片）：

1. 存储空间太少，500M不够用，又不是很想付费（付费还不如买VPS）
2. 没有靠谱的图片处理工具，（我被 Rails 的 Paperclip+Imagemagick 惯坏了……）

如果能把文件上传全交给 S3 的话（不想用 Google Storage），GAE其他问题都不大吧（我的应用规模很小）。

然后我想问一个问题，这里主要是付费用户还是免费用户？
@Livid @ayanamist @fzcs

@tioover GAE现在支持 1.2 的 Django 啊，按照官方文档提供的方法设置一下就好。

@iwinux 没信用卡的只能免费。你提的空间太小不算问题。这个需求只能付费，要不你就gzip一下然后消耗CPU吧。没有靠谱的图片处理确实是个大问题，也没有纯py的实现，gae的那几个太弱了，只能处理下头像都感到吃力
@fanzeyi 你这些都无所谓，生产环境里py25不算低，大部分py2的核心特性都已经支持了，DotCloud还不是py26。py27改变较大，很多模块都不能用了。另外sdk在py27可以用吧……你好像不熟悉py，py2和py3的区别都没搞明白吧
@phus 老大，你为啥不合并我的gzip？而是把那个无关紧要的异常处理给合并了……
@iandyh 用Transaction的一个好处是可以自动重试。我已经shard了，保持small entity做不到（本身已经很小了）。但就算是shard了还是不行啊。关键是应用级的shard一旦弄好，要修改就很麻烦。defer我就不说了。

@ayanamist gzip的补丁我的理解是这样的，作用是goagent的local proxy在收到text/*这种数据的时候，先用gzip压一下再传给浏览器。如果理解无误的话，我的想法是，goagent是本机127.0.0.1回环端口监听的话，压缩和不压缩区别不大，可能会更耗时一点。
这个补丁在goagent作为局域网代理的好处和优势是非常明显的。但这个场景goagent不是很关注，因为goagent作为一个简陋的本机代理(比TwiTalkerPlus简陋很多)，作为局域网代理实在不太胜任啊～～

@phus 我关注啊……我手机靠这玩意儿翻墙呢……我帮你维护可以么……

@ayanamist 显然我是遇到不能用的我才这么说的

@ayanamist 另外我很想知道你从何得来我对py2与py3的区别没搞明白的

gae还是没有ec2好使