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