分类归档: Web

一些网站开发中常用到的Javascript项目

图片轮播 SlideJS

SlidesJS is a responsive slideshow plug-in for jQuery (1.7.1+) with features like touch and CSS3 transitions. Give it a try above and check out the examples to help you get started adding SlidesJS to your project.

官方地址: http://www.slidesjs.com/

 

图片滚动(Marquee) jCarousel

jCarousel是一款 jQuery 插件, 用来控制水平或垂直排列的列表项. 这些项目(可以是静态HTML内容或是Ajax加载内容)内容是可以来回滚动的(可以有动画效果)。

官方地址: http://sorgalla.com/jcarousel/

中文文档:http://www.zhangxinxu.com/jq/jcarousel_zh/

 

图像放大 Etalage

A ready to use jQuery image zooming plugin to present your images in the highest detail without leaving the page.

官方地址:http://frique.me/etalage/

 

简单粗暴的在线编辑器 KindEditor

KindEditor 是一套开源的在线HTML编辑器,主要用于让用户在网站上获得所见即所得编辑效果,开发人员可以用 KindEditor 把传统的多行文本输入框(textarea)替换为可视化的富文本输入框。

官方地址:http://www.kindsoft.net

 

树状列表 zTree

zTree 是一个依靠 jQuery 实现的多功能 “树插件”。优异的性能、灵活的配置、多种功能的组合是 zTree 最大优点。

官方地址:http://www.ztree.me/v3/main.php

 

数据报表 Google Chart

Google chart tools are powerful, simple to use, and free. Try out our rich gallery of interactive charts and data tools.

官方地址:https://developers.google.com/chart/?hl=zh-CN

Read: 325

Subversion SVN 分支 (Trunk/Branch/Tag) 在WEB项目中如何应用?

Trunk = 主干,包含所有开发代码
Branch = 分支其实是主干的copy(svn copy URL URL)。通常用来添加新功能、修改bug、创建发行版等。
Tag = 标记,通常用来做milestone标记,mark某个版本,比如bugfix前后的版本。
以上3个名词其实是版本管理中都概念,在svn中并没有对应功能实现。branch、tag实际上都是用svn copy实现。

感觉svn还是不太适合这种更新频繁的项目。
参考文章

SVN: How to structure your repository

http://ariejan.net/2006/11/24/svn-how-to-structure-your-repository/

SVN: How to release software properly

http://ariejan.net/2006/11/21/svn-how-to-release-software-properly/

Organizing, managing and deploying PHP projects in subversion (SVN)

http://www.ericbieller.com/2011/02/04/organizing-managing-and-deploying-php-projects-in-subversion-svn/

Read: 97

[转]新京报观察:IE6必须死 却没人做得到

src: http://www.donews.com/Content/201003/ce107084fcb3466ca88b6a2d1b7fc0c6.shtm

观察家

  上周末,一群黑衣人聚集在美国丹佛市某会所内,举行了一场葬礼。葬礼现场烛光摇曳,鲜花环绕,悼词卡片放在逝者的棺材周 围。唯一古怪的是,棺材中的“逝者”没有头,它的头部被一张光盘封套取代———上面的遗容是IE6的徽标。这是一场为IE6浏览器举办的非官方葬礼——尽 管据说微软官方的IE6开发小组也送来了卡片,怀念“那段美好的时光”。

  近年来,IE6无论在安全方面,还是在支持互联网新标准方面, 都越来越老态龙钟。震惊世界的Google被黑客入侵事件,其来源就是IE6的一个漏洞;在上述IE6葬礼的官方网站上,也有哀悼者留言:“我不得不无数 次收拾我父亲的计算机,因为他用您观看网络色情内容……好好在地狱里燃烧自己吧,那是你该呆的地儿”。

  尽管如此,IE6短期内仍然不会 被淘汰。业内人戏称,能让IE6死的,只有微软自己;可是微软连续发出IE7、IE8两张王牌,IE6却仍岿然不动。要论置IE6于死地的决心,微软其实 不比Google小——它已经挡了接班人的路。

  这种尴尬境地,其实反映了微软自己在产业体系上的短板。整个微软-英特尔体系的起家契 机,是PC机体系架构的开放;当大量有生产能力的硬件厂家都能生产PC机时,必需的CPU芯片和操作系统便成为战略物资。但在互联网时代,微软已经不复 1980年时的轻松潇洒。现在要背负封闭体系负担的是它自己。一代一代的windows,为了保持与以前软件、设备的兼容,不得不容忍软件体积的空前膨 胀。到了WindowsXP的继任者Vista推出时,这个操作系统的代码量达到了5000万行,动用了9000名程序员。第一代的windows95只 有1500万行。微软自己拖死了自己,才导致Vista在开发三年之后,于2004年突然全部推翻重来。这个夭折,带来了XP的空前长寿,连带着使XP中 捆绑的IE6成为软件界的奇迹。

  中国又是另一种情况。尽管IE6随XP捆绑,但此后的IE7、IE8,和诸多第三方浏览器如 firefox、chrome、safari等,均开放了免费下载,安装也并不复杂,在使用体验上更是远远超过了IE6。因此,在计算机比较普及的欧美国 家,这些非IE浏览器的市场份额不断增加;在欧洲,firefox甚至在2009年还超越了IE6,成为市场份额第一的浏览器。

  但在中 国,即使号称拥有三亿网民,“互联网潜力最大”,在互联网的应用方面却仍然停留在极为原始的水准。IE6尽管无法完整地显示那些美轮美奂的效果、实现高效 的互动,但在偷菜、卖奴隶、逛网店方面已经绰绰有余了。firefox等优秀浏览器在欧洲大出风头的2009年,中国的IE6份额居然反弹到69%。落后 的浏览器背后,反映的是中国互联网低效、重复的应用开发水准。相应地,中国所有银行的网银,现在都只支持IE系浏览器,这成为世界金融界的奇观。

   阴差阳错的业界现实造就了IE6的长寿,而在微软宣布的正式寿命——2014年——之前,IE6的死亡,看来仍有漫漫长路要走。

  曹悦 平(北京媒体从业者)

Read: 1187

Comet:基于 HTTP 长连接的“服务器推”技术

src:http://www.ibm.com/developerworks/cn/web/wa-lo-comet/


周 婷 (zhouting@cn.ibm.com), 软件工程师, IBM 中国软件开发技术实验室

2007 年 8 月 31 日

很 多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器 推”方案,着重介绍了 Comet - 使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案:基于 AJAX 的长轮询方式;基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题,以及如何借助开源的 Comet 框架-pushlet 构建自己的“服务器推”应用。

“服务器推”技术的应用

传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求,譬如:

  • 监控系统:后台硬件热插拔、LED、温度、电压发生变化;
  • 即时通信系统:其它用户登录、发送信息;
  • 即时报价系统:后台数据库内容发生变化;

这 些应用都需要服务器能实时地将更新的信息传送到客户端,而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案,本文将这些解决方案分为两 类:一类需要在浏览器端安装插件,基于套接口传送信息,或是使用 RMI、CORBA 进行远程调用;而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

将“服务器推”应用在 Web 程序中,首先考虑的是如何在功能有限的浏览器端接收、处理信息:

  1. 客户端如何接收、处理信息,是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用,怎么和 JavaScript 结合修改 HTML 的显示。
  2. 客户与服务器端通信的信息格式,采取怎样的出错处理机制。
  3. 客户端是否需要支持不同类型的浏览器如 IE、Firefox,是否需要同时支持 Windows 和 Linux 平台。


基于客户端套接口的“服务器推”技术

Flash XMLSocket

如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行, 那么使用 Flash 的 XMLSocket 也是一个可行的方案。

这种方案实现的基础是:

  1. Flash 提供了 XMLSocket 类。
  2. JavaScript 和 Flash 的紧密结合:在 JavaScript 可以直接调用 Flash 程序提供的接口。

具 体实现方法:在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。

关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序,以及如何在 JavaScript 里调用 Flash 提供的接口,我们可以参考 AFLAX(Asynchronous Flash and XML)项目提供的 Socket Demo 以及 SocketJS(请参见 参考资源)。

Javascript 与 Flash 的紧密结合,极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始,已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于:

  1. 客户端必须安装 Flash 播放器;
  2. 因为 XMLSocket 没有 HTTP 隧道功能,XMLSocket 类不能自动穿过防火墙;
  3. 因为是使用套接口,需要设置一个通信端口,防火墙、代理服务器也可能对非 HTTP 通道端口进行限制;

不过这种方案在一些网络聊天室,网络互动游戏中已得到广泛使用。

Java Applet 套接口

在客户端使用 Java Applet,通过 java.net.Socketjava.net.DatagramSocketjava.net.MulticastSocket 建立与服务器端的套接口连接,从而实现“服务器推”。

这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后,无法通过 JavaScript 去更新 HTML 页面的内容。


回页首

基于 HTTP 长连接的“服务器推”技术

Comet 简介

浏 览器作为 Web 应用的前台,自身的处理功能比较有限。浏览器的发展需要客户端升级软件,同时由于客户端浏览器软件的多样性,在某种意义上,也影响了浏览器新技术的推广。 在 Web 应用中,浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果,通过在浏览器端发送异步请求,提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统,对任何用户来说,可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中,将更新的信息实时传送给客户端,从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。

图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较
图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较

“ 服务器推”是一种很早就存在的技术,以前在实现上主要是通过客户端的套接口,或是服务器端的远程调用。因为浏览器技术的发展比较缓慢,没有为“服务器推” 的实现提供很好的支持,在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年,因为 AJAX 技术的普及,以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题,一些受欢迎的应用如 meebo,gmail+gtalk 在实现中使用了这些新技术;同时“服务器推”在现实应用中确实存在很多需求。因为这些原因,基于纯浏览器的“服务器推”技术开始受到较多关注,Alex Russell(Dojo Toolkit 的项目 Lead)称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架;一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。

下面将介绍两种 Comet 应用的实现模型。

基于 AJAX 的长轮询(long-polling)方式

图 1 所示,AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求,JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于:

  1. 服务器端会阻塞请求直到有数据传递或超时才返回。
  2. 客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后,再次发出请求,重新建立连接。
  3. 当客户端处理接收的数据、重新建立连接时,服务器端可能有新的数据到达;这些信息会被服务器端保存直到客户端重新建立连接,客户端会一次把当前服务器端所有的信息取回。

图 2. 基于长轮询的服务器推模型
图 2. 基于长轮询的服务器推模型

一 些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”(poll),这种长轮询方式也可以称为“拉”(pull)。因为这种方案基于 AJAX,具有以下一些优点:请求异步发出;无须安装插件;IE、Mozilla FireFox 都支持 AJAX。

在 这种长轮询方式下,客户端是在 XMLHttpRequest 的 readystate 为 4(即数据传输结束)时调用回调函数,进行信息处理。当 readystate 为 4 时,数据传输结束,连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持, 即 readystate 为 3 时(数据仍在传输中),客户端可以读取数据,从而无须关闭连接,就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时,不能读取服务器返回的数据,目前 IE 不支持基于 Streaming AJAX。

基于 Iframe 及 htmlfile 的流(streaming)方式

iframe 是很早就存在的一种 HTML 标记, 通过在 HTML 页面里嵌入一个隐蔵帧,然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。

图 3. 基于流方式的服务器推模型
图 3. 基于流方式的服务器推模型

上 节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据,然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端,iframe 服务器端并不返回直接显示在页面的数据,而是返回对客户端 Javascript 函数的调用,如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递;客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

图 3 可以看到,每次数据传送不会关闭连接,连接只会在通信出现错误时,或是连接重建时关闭(一些防火墙常被设置为丢弃过长的连接, 服务器端可以设置一个超时时间, 超时后通知客户端重新建立连接,并关闭原来的连接)。

使 用 iframe 请求一个长连接有一个很明显的不足之处:IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成,而且 IE 上方的图标会不停的转动,表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题,并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth’s of Google’s amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz,封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象,支持 IE、Mozilla Firefox 浏览器,可以作为参考。(请参见 参考资源


回页首

使用 Comet 模型开发自己的应用

上面介绍了两种基于 HTTP 长连接的“服务器推”架构,更多描述了客户端处理长连接的技术。对于一个实际的应用而言,系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用,很多细节需要考虑。

不要在同一客户端同时使用超过两个的 HTTP 长连接

我 们使用 IE 下载文件时会有这样的体验,从同一个 Web 服务器下载文件,最多只能有两个文件同时被下载。第三个文件的下载会被阻塞,直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定,客户端不应该与服务器端建立超过两个的 HTTP 连接, 新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。

HTTP 1.1 对两个长连接的限制,会对使用了长连接的 Web 应用带来如下现象:在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器,第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。

所以在开发长连接的应用时, 必须注意在使用了多个 frame 的页面中,不要为每个 frame 的页面都建立一个 HTTP 长连接,这样会阻塞其它的 HTTP 请求,在设计上考虑让多个 frame 的更新共用一个长连接。

服务器端的性能和可扩展性

一般 Web 服务器会为每个连接创建一个线程,如果在大型的商业应用中使用 Comet,服务器端需要维护大量并发的长连接。在这种应用背景下,服务器端需要考虑负载均衡和集群技术;或是在服务器端为长连接作一些改进。

应 用和技术的发展总是带来新的需求,从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同:1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接; 而 1.1 规范下服务器会保持这个连接,在处理两个请求的间隔时间里,这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时,为这个连接分配的线程资源会返还到线程池,可以供新的连接使用;当原来处于空闲的连接的客户发出新的请求,会从线程池里分配一个线 程资源处理这个请求。 这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。

但 是 AJAX 的应用使请求的出现变得频繁,而 Comet 则会长时间占用一个连接,上述的服务器模型在新的应用背景下会变得非常低效,线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进,请参考文章“AJAX,Comet and Jetty”(请参见 参考资源)。

控制信息与数据信息使用不同的 HTTP 连接

使用长连接时,存在一个很常见的场景:客户端网页需要关闭,而服务器端还处在读取数据的堵塞状态,客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒,然后释放为这个客户端分配的资源,再关闭连接。

所以在设计上,我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接,才能使控制请求不会被阻塞。

在 实现上,如果是基于 iframe 流方式的长连接,客户端页面需要使用两个 iframe,一个是控制帧,用于往服务器端发送控制请求,控制请求能很快收到响应,不会被堵塞;一个是显示帧,用于往服务器端发送长连接请求。如果是基 于 AJAX 的长轮询方式,客户端可以异步地发出一个 XMLHttpRequest 请求,通知服务器端关闭数据连接。

在客户和服务器之间保持“心跳”信息

在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性:因为数据传输是随机的,客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时,释放为这个客户端分配的资源,防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上:

  1. 服务器端在阻塞读时会设置一个时限,超时后阻塞读调用会返回,同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭,服务器往通道写数据会出现异常,服务器端就会及时释放为这个客户端分配的资源。
  2. 如果客户端使用的是基于 AJAX 的长轮询方式;服务器端返回数据、关闭连接后,经过某个时限没有收到客户端的再次请求,会认为客户端不能正常工作,会释放为这个客户端分配、维护的资源。
  3. 当服务器处理信息出现异常情况,需要发送错误信息通知客户端,同时释放资源、关闭连接。

Pushlet – 开源 Comet 框架

Pushlet 是一个开源的 Comet 框架,在设计上有很多值得借鉴的地方,对于开发轻量级的 Comet 应用很有参考价值。

观察者模型

Pushlet 使用了观察者模型:客户端发送请求,订阅感兴趣的事件;服务器端为每个客户端分配一个会话 ID 作为标记,事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。

客户端 JavaScript 库

pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”;还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。

JavaScript 库做了很多封装工作:

  1. 定义客户端的通信状态:STATE_ERRORSTATE_ABORTSTATE_NULLSTATE_READYSTATE_JOINEDSTATE_LISTENING
  2. 保存服务器分配的会话 ID,在建立连接之后的每次请求中会附上会话 ID 表明身份;
  3. 提供了 join()leave()subscribe()unsubsribe()listen() 等 API 供页面调用;
  4. 提供了处理响应的 JavaScript 函数接口 onData()onEvent()

网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。

客户端与服务器端通信信息格式

pushlet 定义了一套客户与服务器通信的信息格式,使用 XML 格式。定义了客户端发送请求的类型:joinleavesubscribeunsubscribelistenrefresh;以及响应的事件类型:datajoin_acklisten_ackrefreshheartbeaterrorabortsubscribe_ackunsubscribe_ack

服务器端事件队列管理

pushlet 在服务器端使用 Java Servlet 实现,其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。

Pushlet 支持客户端自己选择使用流、拉(长轮询)、轮询方式。服务器端根据客户选择的方式在读取事件队列(fetchEvents)时进行不同的处理。“轮询”模式下 fetchEvents() 会马上返回。”流“和”拉“模式使用阻塞的方式读事件,如果超时,会发给客户端发送一个没有新信息收到的“heartbeat“事件,如果是“拉”模式,会把“heartbeat”与“refresh”事件一起传给客户端,通知客户端重新发出请求、建立连接。

客户服务器之间的会话管理

服务端在客户端发送 join 请求时,会为客户端分配一个会话 ID, 并传给客户端,然后客户端就通过此会话 ID 标明身份发出 subscribelisten 请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。

服务器端的事件源会把新产生的事件以多播的方式发送到每个会话(即订阅者)的事件队列里。


回页首

小结

本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用,最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用, 目前开发 Comet 应用还是具有一定的挑战性。

“ 服务器推”存在广泛的应用需求,为了使 Comet 模型适用于大规模的商业应用,以及方便用户构建 Comet 应用,最近几年,无论是服务器还是浏览器都出现了很多新技术,同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展,相信 Comet 的应用会变得和 AJAX 一样普及。

参考资料

学习

获得产品和技术

  • Jetty:下载 Jetty。

讨论

关于作者

周婷,软件工程师,目前在 IBM 中国软件开发技术实验室从事刀片服务器管理固件的开发工作。您可以通过 zhouting@cn.ibm.com 和她联系。

Read: 1142

号称目前最快的 Web 服务器软件 — Cherokee

Cherokee 号称是目前最快的 Web 服务器软件,在性能上,甚至比 Nginx 还略胜一筹。与 Apache、Lighttpd、Nginx 等其他同类软件的对比,大家不妨看看这个测试页面。其易用性做得也很不错。

Cherokee 的功能包括支持 FastCGI、SCGI、PHP、CGI、TLS 及 SSL 加密连接,虚拟主机,授权认证,实时编码,载入均衡,与 Apache 兼容的 log 文件等等。

Cherokee 内含一个名为 cherokee-admin 的工具,执行后,允许管理员直接通过浏览器进入 http://localhost:9090/ 对其进行管理和配置。比如,开启或关闭服务器,进行一般选项的设定,配置虚拟服务器、信息源、图标、Mime 类型等项目。

Read: 943