云服务 [小调查] 关于大家对又拍云的使用看法~

upyun · 2012年05月30日 · 最后由 siyang1982 回复于 2012年09月26日 · 4635 次阅读

目前又拍云存储已经在 ruby-china 上面也已经举办了两次赠送活动了,赠送的用户受众也有一批了,但是,有很大一部分的用户的账户里面的流量都还没有开始使用,所以,想看看大家都是什么想法,以便我们能够及时的做出改进~ 谢谢大家~

因为要手机号所以还没有注册。。。期望早日取消

#1 楼 @donnior 这样啊,是这样的,要手机号是为了防止你忘记了密码可以用手机找回密码~哈哈~

那注册时为什么需要邮箱呢?

#3 楼 @charles 哪里注册不要邮箱啊!

大家水平菜,还没开始玩呢?只是注册下,具体怎么玩还不知道呢。

都挺好的,一直用着很顺手。 唯一一点是浏览器 cache 时间是 7 天,能不能自己设定,我的设计都是可以永久 cache 的,新文件都会换个文件名。

#6 楼 @huacnlee 我们这里的缓存时间是 7 天 ,这个暂时应该没办法改变啊,不过客户端那里的缓存数据 7 天后还存在的话还是有效的~

#7 楼 @upyun

根据目前的 FORM API 来看, ReturnURL 和 NotifyURL 内返回的信息 (如下) 都没有 bucket 信息,

{"code"=>"200", "message"=>"ok", "url"=>"/2012/09/a04670cac9bc2f4cca86c63dc2403c99.png", "time"=>"1348317633", "image-width"=>"200", "image-height"=>"200", "image-frames"=>"1", "image-type"=>"PNG", "sign"=>"8294dcbdfa669c8a24dcdf0097159d0e"} 

由于 notify 是异步过程,当 notify 成功后,我这边并不能确定文件传到哪个 bucket 里去了,而 bucket 又是我构造该文件访问 url 的必须项,所以建议能将本次请求的 bucket 也返回来,并且该 bucket 要参与签名,保证传输过程中没有被篡改

#8 楼 @huobazi hi,这个问题因为还涉及了兼容性的问题,所以我们这边会讨论一下是否具有可行性,感谢你的建议哈~

匿名 #10 2012年09月24日

没用过,只用过 heroku、openshift、cloud foundry

#10 楼 @help5305fff 哈哈,可以注册一个免费测试一下~也没什么损失的 :)

#9 楼 @upyun 你们应该有考虑 API 的版本机制吧,一般 API 的设计都会考虑到版本,升版本并不影响原版本功能即可兼容。从目前情况来看,我没有找到其他能确定该异步过程完毕后的 bucket,而无法拼出访问地址,同样类似这样的需求随着使用者越多肯定会越来越多,API 势必需要升级。另外再提一个,目前 upyun 的 API 没有移动文件的 API,当如下场景时我就需要能够移动文件,举个例子,可能不适用,但可说明问题,At 一下 @huacnlee ,比如在 ruby-china 发/回贴时传文件时文件是先传到 upyun,而帖子是后生成的,我可以在帖子生成前上传的图片放入/temp/a/b/c.jpg 等用户真的生成了帖子后,从 temp 目录移动到真实目录,然后定期跑 job 将 temp 目录内的无主文件清理掉,不致浪费存储空间。 移动文件的 API 在其他云存储比如七牛是支持的。

#12 楼 @huobazi hi,刚才跟产品那边有沟通了一下,他们觉得这个是可以有的,我们将会把您提的 API 版本机制和移动文件的 API 列入后期的产品升级的计划中~ 感谢您的建议~

#13 楼 @upyun 哦。有用就好,也希望 upyun 越来越好。

赞。 测试过程中,遇到过几次图片上传完成后,其中某缩略图取不到。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号