博文

目前显示的是 五月, 2014的博文

我的又一个 fuse 客户端——upyunfs

我写 fuse 客户端可能有点上瘾,是因为我觉得对于在线存储类的服务,能够映射到本地存储,对用户来说是路径最短,学习成本最低、体验最友好的方式。而要实现类似的效果,据我所知要么用 fuse 把远端的存储挂载到本地(如 sshfs、amazon s3fs),要么写个后台服务实现本地和远端的双向同步(同步远端可以轮询或用某种 push 技术,同步本地可以用 inotify,典型案例是 dropbox)。而我之所以倾向前者,是因为 fuse 的实现成本要小很多,对于个人开发者来说性价比完胜。

有了上述前提,什么专门的 GUI 管理工具啦,专门的 shell 啦,在我看来都比较无聊——当远端的文件系统已经变成本地的一部分时,用户可以使用任意自己熟悉的文件管理工具(无论 GUI 还是 CLI),可以使用任意自己熟悉的 shell 环境(包括相应的各种工具),来完成对远端的文件管理任务。比如将 dropbox 同步到 upyun,在我看来只需要这样就可以了:
upyunfs -b lyman_foo ~/cloud/upyun # 挂载 upyunfs
rsync -avh ~/cloud/dropbox/ ~/cloud/upyun/ # 用 rsync 同步两个文件夹 所以看到 upyun 搞了开发者比赛的时候,我实在是忍不住,便写了这个 upyunfs

对实现细节不感兴趣的同学可以忽略下面的文字了,不过还是希望各位能给 upyunfs 投个票:到项目页面里找到 upyunfs-for-UPYUN,点击「投票」按钮即可。

接下来大概分析一下 upyunfs(以及类似存储系统)的实现要点。

一、技术选择

fuse 有各种语言的 binding,从执行效率角度考虑首选当然是 c/c++。但是如 upyun 这样提供 RESTful 接口的服务,用到字符串操作的地方不少,所以用脚本写起来更方便。python 的 binding 我试过一次,问题不少文档不多,所以我一直用 perl。

二、roadmap

基本功能
这个阶段基本上只要做好 fuse 回调和 RESTful api 的映射就好了。具体一点,在线存储系统基本上必不可少的 upload/download/list 操作,大抵就可以对应到 fuse 的 read/write/getdir 上。此时如果有合手的 sdk,完成…

再见,delicious

曾几何时,delicious 就是在线书签的代名词。但是就在刚刚,我把自己的书签都搬到了 diigo

delicious 自 2003 年出现,2005 年被 yahoo! 收购,2010 年被 yahoo! 宣布关闭,2011 年被 avos 挽救,到今天,一直不死不活,苟延残喘,而我也一直坚持用它。

今天翻看自己的 delicious 页面,才发现丢了近一周的数据。大概是 5 月 4 日起,虽然 chrome 的插件、firefox 的插件在使用时没有抱怨什么,但新书签却再也没出现在我的 delicious 里。

理想不能当饭吃。

我对在线书签的要求也不高:能打标签,别人能订阅、支持主流浏览器足矣。在感受了 digg、pocket、google bookmark 和 diigo 之后,最终选择了 diigo(温馨提示,google bookmark 看起来很有步 google reader 后尘的感觉)。

彻底自由的做法,或许应该是通过自由的浏览器插件、手机客户端存储到本地,然后通过类似 dropbox、btsync 之类实现中央存储或者多点同步。只不过这么理想化的解决方式,在今天凡事都想被做成在线服务的大环境里,越发缺少生存的土壤。

祝 diigo 长命百岁吧。