寻找：lightweight photo/video gallery and microblogging archiver

1. picasa ?

@bhuztez 需要自己建站。而不是依托别人的服务。自己的数据自己保管最好。

况且Picasa对大图还有尺寸和文件大小限制。让我20多MB的JPEG全景图情何以堪。

@est 20多MB的JPEG 你自己用 Web 做也不好做吧

@bhuztez 不太明白，哪里做不好？有保存原始大图正是自己建站的好处呀。

@est 但你浏览的时候得是别的尺寸啊，难道你每次都看原始大图？

@bhuztez 哦。缩略图这个基本功能肯定是任意photo gallery程序都有的吧。

@est 缩图很费 CPU 时间，所以你只能，在上传后在后台排队缩成固定的几种尺寸。20M的原图，即时处理是来不及的。我感觉很多开源的都是直接在相同进程用 GD 处理下吧，没仔细看代码，也许我是错的。

@bhuztez 后台队列处理可以接受。。。但是那样的程序不存在？

我又想自己造轮子了。

@est 造吧。

自己的vps还是用自己的程序好玩。

@Jet 这这这您这是逼我挖火炕啊。

@est 我已经挖了很多火坑了还跳了不少啊亲！！

@est 正好可以用来试试 Tornado 或者 Celery 的异步任务处理……

@est 其实我已经造了小半个了

@Livid 我计划中的还用不着高级的异步模块。一个subprocess开启ImageMagick压图，然后监视子进程，是否结束，结束则回调函数，出错则调用异常。
@bhuztez 发出来围观一下？

@Livid 多年前的footbig还会有下文么？搞一个分布式的图片SNS来玩玩？

@est 还拼不起来，只能说下大致的情况。测试结果表明 GraphicsMagick 比 ImageMagick 快那么一点，JPEG库，libjpeg-turbo又比libjpeg快那么点。队列用 gearmand ，为了让它监听 unix socket ，我用 Twisted 写了个。WSGI Server，在 flup 的基础上，把 SCGI 折腾成可以像 FastCGI 那样监听从 fd0 传进来的 socket，这样就能配合 supervisord 了，现在正在想怎么支持 X-Sendfile， prefork 的处理方式打算抄袭一下 unicorn ，另外再山寨一份 supervisord ，supervisord 蛋疼的地方是不支持用 unix socket 连进来进程的 uid 认证。

你可以在Github同ID上找到相关代码，现在还没文档，有些地方还不稳定。

你确定监视子进程真的有用？测试表明 1024x1024 的JPEG图片，还算不错的CPU上，单核一秒也就只能 10 张。你那是 20M ，处理时间要好几秒都很有可能吧，还有为了照顾浏览体验，你可能需要在上传的时候，生成多个尺寸的缩略图。20M 的用 HTTP 上传本身就显得很坑爹了。也许还是 FTP 或者 SSH 上传，inotify 折腾下？

@bhuztez

> 20M 的用 HTTP 上传本身就显得很坑爹了

我记得HTML5可以读取文件blob？可以试试分块上传。

http://theopenphotoproject.org/overview

http://www.techbits.de/2011/10/25/building-a-google-plus-inspired-image-gallery/

找到了！理想中的东东！

@yoyicue OpenPhotoProject图片可以是S3和dropbox上的。迁移成本哪里大呢？

@est 我没说 OpenPhotoProject 不合适, 我强调的是 VPS 不合适.