我正在使用优秀的Fog gem来访问Rackspace Cloud Files服务.我的挑战是,我正在努力保持访问云文件的服务轻量级,而且似乎Fog通过其灵活性具有很多依赖性和代码,我永远不需要.
有没有人试图构建一个精简的Fog副本,只是为了包含一部分提供者,因此限制了依赖关系？例如,对于Rackspace Cloud Files API,我希望能够处理所有没有net-ssh,net-scp,nokogiri gems以及Amazon,Rackspace和其他20个未使用的代码的未使用代码.用过的.我希望每当其中一个未使用的提供商注意到一个bug时,就会避免升级gem,同时保持内存占用率下降.
我很感激任何人在这方面可能有的经验,或者任何熟悉我能够并且不能扯掉Fog的人的建议.
如果我只是使用错误的宝石,那就同样好了.我会转向更专注的事情.
gee*_*mus 10
我是雾的维护者,所以我会帮助填补一些解释/空白.简短的回答是,是的,这是很多东西,但大多数情况下它不会对你造成负面影响.
首先,雾随着时间的推移有机地增长,所以它确实比预期更大.我们与之抗衡的方法之一是,我们宁愿主动避免在真正需要之前需要/加载文件.因此,虽然您必须下载许多不会用于安装雾的提供程序文件,但它们实际上不应该最终存储在内存中.这是我们可以做的最简单的事情,以保持"正常工作",同时减少内存使用(和加载时间).
发布时间表并不会过于疯狂(平均每月一次),并且往往包含大多数提供商的混合内容.所以我希望你不会有太多的流失(在紧急/安全类型修复之外可能需要缩短正常周期).
因此,希望能够为现有技术提供一些见解.我们还讨论了从长远来看开始分解的问题.我认为如果/当发生这种情况时,我们最终会得到类似fog-rackspace所有与机架空间相关的东西.然后他们可以通过fog-core或类似的方式分享内容.我们有一个粗略的轮廓,但它是一个相当大的事业没有巨大的上升,所以它不是我们真正积极开始的东西.
如果您有其他问题或疑虑,希望有所帮助,当然乐意进一步讨论.
我在Rackspace上工作,其中包括我们的Ruby SDK.你正在使用正确的宝石.Fog是我们的官方Ruby API.
这可能是通过将另一个gemspec引入到仅由雾核心和Rackspace特定文件构建的项目中来完成的.虽然这将是非常规的,并使@geemus'(宝石维护者)宝石发布过程更加复杂 - 特别是其他供应商应该开始做同样的事情.从长远来看,这将有助于将雾社区从作为统一API的角色转移.
| 归档时间： |
|
| 查看次数： |
786 次 |
| 最近记录： |