看新闻的时候，突然看到phpmyadmin出了3.0beta版本，只是好象新版本是基于5.2开发的。源码地址为：http://internap.dl.sourceforge.net/sourceforge/phpmyadmin/phpMyAdmin-3.0.0-beta-all-languages.zip，大家可以去下载，如果不能下载，可以先到：http://sourceforge.net/projects/phpmyadmin/，找到3.0beta版进行下载。

对于使用PHP进行开发的人员来说，phpmyadmin可以说是最常用的工具之一。其重要性不亚于一个好的IDE所带来的功效。

SF上面如此提示：

Welcome to the beta release of phpMyAdmin 3.0.0. This version supports various features of MySQL 5.1, the Maria and PBXT storage engines and  
SweKey hardware authentication. The 3.0 series requires PHP 5.2+ and MySQL 5.0+.

看到cnbeta上有人评价说：phpmyadmin不是利器，而是神器。心中亦有此感啊。

下载源码，学习一下。oh yeah

写代码的时候不可避免的会使用到注释。大多数的情况下，我们都是使用<!-- 这里是注释 -->，因为这是HTML自带的注释功能，在这里的代码都不会被显示到浏览器。

然而，使用了smarty之类，我们确实不是很建议这样使用，因为，在<!---->标记里的smarty代码其实还是被解析了，如果是这样的话，那么，我们其实是多做了很多事情，却没有被显示出来，那就是说，我们其实多做了很多无用功。

因此，我们在使用smarty模版的时候，应该根据smarty的规范来。让我们看看手册怎么说：

 所有例子中，我们假定你使用缺省的分隔符。Smarty中，所有在分隔符之外的内容被显示为静态内容，或者说不会被改变。一旦Smarty遇见分隔符，它将尝试解释它们，然后在其位置处显示合适的内容。

注释

    模板注释由星号包围，继而由分隔符包围，型如：{* 这是一个注释 *}。Smarty注释不会在最终模板的输出中显示，这点和<!-- HTML comments -->不同。前者对于在模板中插入内部注释有用，因为没有人能看到。;-)

smarty中的变量和平时使用有点区别，比如$aa.bb其实代表的是$aa['bb']，具体如何个使用法，其实在手册里已经有详细说明了

    Smarty可以识别嵌入在双引号中赋值的变量，只要变量名只包含数字，字母，下划线和方括号[]（参见命名）。如果有其它字符（如句点，对象引用等），变量必须由反引号对`backticks`包含。你不可以嵌入修饰符，它们必须永远在引号之外使用。

实际使用中应该是这样的：

语法例子：
{func var="test $foo test"}       <-- 使用$foo
{func var="test $foo_bar test"}   <-- 使用$foo_bar
{func var="test $foo[0] test"}    <-- 使用$foo[0]
{func var="test $foo[bar] test"}  <-- 使用$foo[bar]
{func var="test $foo.bar test"}   <-- 使用$foo（不是$foo.bar）
{func var="test `$foo.bar` test"} <-- 使用$foo.bar
{func var="test `$foo.bar` test"|escape} <-- 修饰符在引号外！

实际例子：
{include file="subdir/$tpl_name.tpl"} <-- 将以实际值替换$tpl_name
{cycle values="one,two,`$smarty.config.myval`"} <-- 必须有反引号！

看清楚哦。平时在使用的时候应该是感觉不出问题的，只有用在函数、循环里面，这才会成为使用中的问题。

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

1. 自由地再发布

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

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

2. 源代码

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

3. 派生作品

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

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

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

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

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

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

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

7. 许可证的发布

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

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

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

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

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

» 阅读全文

比较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
仅作参考