易栈网-膘叔

国内很多软件开发在叫嚣着开源，但，有几个是真正做到的？最初的discuz，直到现在还是有一些目录是加密的，主要是一些API，现在又看到不少自称是开源的。请你们扪心自问，你们做到了吗？
虽然国内开发人员的素质参差不齐，但靠欺骗的手段来达到听引人的目录，你们对得起自己的良心吗？？
什么是开源？？？看看吧。。。
开放源代码并不仅仅意味着对源代码的访问权。开放源代码软件的发布条款必须满足以下条件：

1. 自由地再发布

如果被发布的软件是由不同来源的程序组成的，许可证不得限制任何当事人或组织（party）销售或赠送作为被发布软件成分之一的开放源码软件。

许可证不得从此项销售中索取使用费或其它任何费用。（理由）

2. 源代码

程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支 付合理范围之外的任何费用的手段以获得源代码---从网络上免费下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含 混晦涩是不允许的。也不允许给出预处理器或翻译器处理的中间结果。（理由）

3. 派生作品

许可证必须允许修改软件和派生软件，并且必须允许它们按照原软件的许可证的条款进行发布。（理由）

4. 作者的源代码的完整性

只有在许可证允许与源代码一同发布"补丁文件"（该"补丁文件"以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的发布。许可证必 须明确地允许发布由修改后的源代码生成的程序。许可证可以要求派生的作品采用不同的名称或不同的版本号以区别于原来的软件。（理由）

5. 不得歧视任何个人或团体

许可证不得歧视任何个人或者由多人组成的团体。（理由）

6. 不得歧视任何应用领域（fields of endeavor）

许可证不得限制任何人把程序应用于任何领域。例如，不得规定程序不能应用于商业领域或基因研究领域。（理由）

7. 许可证的发布

与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者也不需要为了使用该程序而获得其它许可证的许可。（理由）

8. 许可证不能针对于一个产品

与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。（理由）

9. 许可证不能影响其它软件

许可证不得向与采用它的软件一同发布的其它软件提出任何限制。例如，许可证不能坚持要求在同一媒体上发布的其它程序都是开放源代码软件。（理由）

» 阅读全文

几天不见，YUI居然release了，虽然是preview版本。
官方这么说：

The YUI development team has issued YUI 3.0 Preview Release 1, an early look at the next generation of the Yahoo! User Interface Library (YUI). This developer preview shows you where the library is headed as we pursue goals of size, performance, consistency, power, security, and openness.

You can read the introduction to the new release on YUIBlog and get a sense of the new syntactical style in this blog post, which reviews Dav Glass's Draggable Portable example — one of more than 60 examples that accompany the preview's extensive documentation.

YUI 3.0 PR 1 is an early preview — not suitable for production deployment. The development team is looking forward to your feedback in the YUI 3.x community forum as we refine the API toward a 2009 release.

Work continues on YUI's main 2.x codeline, too, and YUI 2.x is still the foundation for current projects. Check out the library's Roadmap for a up-to-date picture of what we're planning for upcoming releases.

有点期待。

Copy from framework.zend.com , it's submitted of Thursday, July 31, 2008
It's full contents :

and someone were comments for this news,

这样看来，以后ADOBE或许也会主动参与了吧？

本文来自于天极网。意见不敢苟同，COPY过来也是想听听大家的意见。
原文如下：

在作者眼里，PHP好象就只能处于低层次的开发。其实开发这东西也是双面性的，你让一个新手写JAVA和让我一个老手写PHP，写出来的东西你认为哪个值钱？
之所以JAVA比PHP值钱，归根结底还是观念，大多数人认为JAVA是科班出身，而PHP则是扎根草堆，虽然最近两年也开始逐步有培训班的出现，但和JAVA比起来就差远了。
就象大腕里说的：你要用PHP写的OA，你都不好意思提出口，怎么着也得是JAVA，.NET之类的吧。

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息
用于传送信息的传输协议(例如，通道数)
用于所有可使用功能的名称和接口使用方法
在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71772.html
仅作参考