php:一个允许包含url的例子是个好主意?

与这里的其他回应者相反,我要说“不”。我想不出任何情况下这会是个好主意。

对其他想法的一些快速反应:

• 许可:将是 非常 容易规避
• 多个服务器的单一库:很抱歉,这是一个非常愚蠢的解决方案,应该通过同步来自例如a的文件来解决。
  • 源控制系统
  • 包装/配送系统
  • 构建系统
  • 或者远程文件系统。提到了NFS
• Google的远程库:没有人会受益于在PHP上缓慢加载非缓存的PHP库。这不是(异步)javascript

我想我涵盖了所有这些……

现在。。

你的问题是“包括其他地方托管的文件”,我认为你不应该尝试。但是,也有允许使用“url”包括。此设置不仅仅包括http://。它还包括用户定义的协议处理程序,我甚至相信phar://。对于这些,有相当多的有效用途。

我能想到的只有:

1. 对于远程库,例如 google api's .
2. 或者,如果您是Facebook这样的用户,在不同的位置使用devs,devs的使用包括来自不同的阶段服务器(db、dev、staging、production)。
3. 在开发过程中,再次向第三方程序进行测试版转换,因此您总是可以在不必编译自己的情况下获得最新的版本(例如,使用将要针对其构建的远程Tinymce测试版将在进入生产之前完成)。

但是,如果远程服务器出现故障,它会杀死应用程序,因此对于大多数人来说,这对于生产使用来说不是一个好主意。

这里有一个我能想到的例子。

在我的组织里,我的部门负责内部网和因特网站点。因为我们使用的是两个不同的服务器,在我们的例子中是两个不同的子域,所以我可以看到一种情况,即两个服务器都使用一个库。这将允许两个服务器使用相同的类。这不是一个安全问题,因为您可以完全控制这两个服务器,并且比维护同一类的两个版本要好。

由于您拥有对服务器的控制权,并且拥有面向外部的服务器和内部服务器需要分离(因为防火墙),那么,这将是一个比在两个位置保存同一类的副本更好的解决方案。

隐马尔可夫模型。。。

[此处插入桶刮噪音]

…您可以使用这是许可软件的一种方式-因为许可证密钥等可以存储在远程系统上(由卖方管理)。通过这样做,卖方将保留对试图访问密钥的所有系统的控制权。

然而,正如你所说的,这是一个可怕的想法,超过了我心目中的任何积极因素。