mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-21 02:10:11 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
3cd0fbf268
@ -1,3 +1,12 @@
|
||||
language: c
|
||||
script:
|
||||
- sh ./scripts/check.sh
|
||||
- ./scripts/badge.sh
|
||||
|
||||
deploy:
|
||||
provider: pages
|
||||
skip_cleanup: true
|
||||
github_token: $GITHUB_TOKEN
|
||||
local_dir: build
|
||||
on:
|
||||
branch: master
|
||||
|
||||
@ -1,25 +1,25 @@
|
||||
CPU 电源管理工具 - Linux 系统中 CPU 主频的控制和管理
|
||||
CPU 电源管理器：Linux 系统中 CPU 主频的控制和管理
|
||||
======
|
||||
|
||||
|
||||
|
||||
你使用笔记本的话，可能知道 Linux 系统的电源管理做的很不好。虽然有 **TLP**、[**Laptop Mode Tools** 和 **powertop**][1] 这些工具来辅助减少电量消耗，但跟 Windows 和 Mac OS 系统比较起来，电池的整个使用周期还是不尽如意。此外，还有一种降低功耗的办法就是限制 CPU 的频率。这是可行的，然而却需要编写很复杂的终端命令来设置，所以使用起来不太方便。幸好，有一款名为 **CPU Power Manager** 的 GNOME 扩展插件，可以很容易的就设置和管理你的 CPU 主频。GNOME 桌面系统中，CPU Power Manager 使用名为 **intel_pstate** 的功率驱动程序（几乎所有的 Intel CPU 都支持）来控制和管理 CPU 主频。
|
||||
你使用笔记本的话，可能知道 Linux 系统的电源管理做的很不好。虽然有 **TLP**、[**Laptop Mode Tools** 和 **powertop**][1] 这些工具来辅助减少电量消耗，但跟 Windows 和 Mac OS 系统比较起来，电池的整个使用周期还是不尽如意。此外，还有一种降低功耗的办法就是限制 CPU 的频率。这是可行的，然而却需要编写很复杂的终端命令来设置，所以使用起来不太方便。幸好，有一款名为 **CPU Power Manager** 的 GNOME 扩展插件，可以很容易的就设置和管理你的 CPU 主频。GNOME 桌面系统中，CPU Power Manager 使用名为 **intel_pstate** 的频率调整驱动程序（几乎所有的 Intel CPU 都支持）来控制和管理 CPU 主频。
|
||||
|
||||
使用这个扩展插件的另一个原因是可以减少系统的发热量，因为很多系统在正常使用中的发热量总让人不舒服，限制 CPU 的主频就可以减低发热量。它还可以减少 CPU 和其他组件的磨损。
|
||||
|
||||
### 安装 CPU Power Manager
|
||||
|
||||
首先，进入[**扩展插件主页面**][2]，安装此扩展插件。
|
||||
首先，进入[扩展插件主页面][2]，安装此扩展插件。
|
||||
|
||||
安装好插件后，在 GNOME 顶部栏的右侧会出现一个 CPU 图标。点击图标，会出现安装此扩展一个选项提示，如下示：
|
||||
|
||||
|
||||
|
||||
点击**“尝试安装”**按纽，会弹出输入密码确认框。插件需要 root 权限来添加 policykit 规则，进而控制 CPU 主频。下面是弹出的提示框样子：
|
||||
点击“尝试安装”按纽，会弹出输入密码确认框。插件需要 root 权限来添加 policykit 规则，进而控制 CPU 主频。下面是弹出的提示框样子：
|
||||
|
||||
|
||||
|
||||
输入密码，点击**“认证”**按纽，完成安装。最后在 **/usr/share/polkit-1/actions** 目录下添加了一个名为 **mko.cpupower.setcpufreq.policy** 的 policykit 文件。
|
||||
输入密码，点击“认证”按纽，完成安装。最后在 `/usr/share/polkit-1/actions` 目录下添加了一个名为 `mko.cpupower.setcpufreq.policy` 的 policykit 文件。
|
||||
|
||||
都安装完成后，如果点击右上脚的 CPU 图标，会出现如下所示：
|
||||
|
||||
@ -27,12 +27,10 @@ CPU 电源管理工具 - Linux 系统中 CPU 主频的控制和管理
|
||||
|
||||
### 功能特性
|
||||
|
||||
* **查看 CPU 主频:** 显然，你可以通过这个提示窗口看到 CPU 的当前运行频率。
|
||||
* **设置最大最小主频:** 使用此扩展，你可以根据列出的最大、最小频率百分比进度条来分别设置其频率限制。一旦设置，CPU 将会严格按照此设置范围运行。
|
||||
* **开/关 Turbo Boost:** 这是我最喜欢的功能特性。大多数 Intel CPU 都有 “Turbo Boost” 特性，为了提高额外性能，其中的一个内核为自动进行超频。此功能虽然可以使系统获得更高的性能，但也大大增加功耗。所以，如果不做 CPU 密集运行的话，为节约电能，最好关闭 Turbo Boost 功能。事实上，在我电脑上，我大部分时间是把 Turbo Boost 关闭的。
|
||||
* **生成配置文件:** 可以生成最大和最小频率的配置文件，就可以很轻松打开/关闭，而不是每次手工调整设置。
|
||||
|
||||
|
||||
* **查看 CPU 主频：** 显然，你可以通过这个提示窗口看到 CPU 的当前运行频率。
|
||||
* **设置最大、最小主频：** 使用此扩展，你可以根据列出的最大、最小频率百分比进度条来分别设置其频率限制。一旦设置，CPU 将会严格按照此设置范围运行。
|
||||
* **开/关 Turbo Boost：** 这是我最喜欢的功能特性。大多数 Intel CPU 都有 “Turbo Boost” 特性，为了提高额外性能，其中的一个内核为自动进行超频。此功能虽然可以使系统获得更高的性能，但也大大增加功耗。所以，如果不做 CPU 密集运行的话，为节约电能，最好关闭 Turbo Boost 功能。事实上，在我电脑上，我大部分时间是把 Turbo Boost 关闭的。
|
||||
* **生成配置文件：** 可以生成最大和最小频率的配置文件，就可以很轻松打开/关闭，而不是每次手工调整设置。
|
||||
|
||||
### 偏好设置
|
||||
|
||||
@ -40,24 +38,23 @@ CPU 电源管理工具 - Linux 系统中 CPU 主频的控制和管理
|
||||
|
||||
|
||||
|
||||
如你所见，你可以设置是否显示 CPU 主频，也可以设置是否以 **Ghz** 来代替 **Mhz** 显示。
|
||||
如你所见，你可以设置是否显示 CPU 主频，也可以设置是否以 **Ghz** 来代替 **Mhz** 显示。
|
||||
|
||||
你也可以编辑和创建/删除配置:
|
||||
你也可以编辑和创建/删除配置文件：
|
||||
|
||||
|
||||
|
||||
可以为每个配置分别设置最大、最小主频及开/关 Turbo boost。
|
||||
可以为每个配置文件分别设置最大、最小主频及开/关 Turbo boost。
|
||||
|
||||
### 结论
|
||||
|
||||
正如我在开始时所说的，Linux 系统的电源管理并不是最好的，许多人总是希望他们的 Linux 笔记本电脑电池能多用几分钟。如果你也是其中一员，就试试此扩展插件吧。为了省电，虽然这是非常规的做法，但有效果。我确实喜欢这个插件，到现在已经使用了好几个月了。
|
||||
|
||||
What do you think about this extension? Put your thoughts in the comments below!你对此插件有何看法呢？请把你的观点留在下面的评论区吧。
|
||||
你对此插件有何看法呢？请把你的观点留在下面的评论区吧。
|
||||
|
||||
祝贺!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/cpu-power-manager-control-and-manage-cpu-frequency-in-linux/
|
||||
@ -65,7 +62,7 @@ via: https://www.ostechnix.com/cpu-power-manager-control-and-manage-cpu-frequenc
|
||||
作者：[EDITOR][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[runningwater](https://github.com/runningwater)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,27 +1,27 @@
|
||||
万维网的创建者正在创建一个新的分布式网络
|
||||
万维网的创建者正在创建一个新的去中心化网络
|
||||
======
|
||||
|
||||
**万维网的创建者 Tim Berners-Lee 公布了他计划创建一个新的分布式网络，网络中的数据将由用户控制**
|
||||
> 万维网（WWW）的创建者 Tim Berners-Lee 公布了他计划创建一个新的去中心化网络，该网络中的数据将由用户控制。
|
||||
|
||||
[Tim Berners-Lee] [1]以创建万维网而闻名，万维网就是你现在所知的互联网。二十多年之后，Tim 致力于将互联网从企业巨头的掌控中解放出来，并通过分布式网络将权力交回给人们。
|
||||
[Tim Berners-Lee][1] 以创建万维网而闻名，万维网就是你现在所知的互联网。二十多年之后，Tim 致力于将互联网从企业巨头的掌控中解放出来，并通过<ruby>去中心化网络<rt>Decentralized Web</rt></ruby>将权力交回给人们。
|
||||
|
||||
Berners-Lee 对互联网“强权”们处理用户数据的方式感到不满。所以他[开始致力于他自己的开源项目][2] Solid “来将在网络上的权力归还给人们”
|
||||
Berners-Lee 对互联网“强权”们处理用户数据的方式感到不满。所以他[开始致力于他自己的开源项目][2] Solid “来将在网络上的权力归还给人们”。
|
||||
|
||||
> Solid 改变了当前用户必须将个人数据交给数字巨头以换取可感知价值的模型。正如我们都已发现的那样，这不符合我们的最佳利益。Solid 是我们如何驱动网络进化以恢复平衡——以一种革命性的方式，让我们每个人完全地控制数据，无论数据是否是个人数据。
|
||||
> Solid 改变了当前用户必须将个人数据交给数字巨头以换取可感知价值的模型。正如我们都已发现的那样，这不符合我们的最佳利益。Solid 是我们如何驱动网络进化以恢复平衡 —— 以一种革命性的方式，让我们每个人完全地控制数据，无论数据是否是个人数据。
|
||||
|
||||
![Tim Berners-Lee is creating a decentralized web with open source project Solid][3]
|
||||
|
||||
基本上，[Solid][4]是一个使用现有网络构建的平台，在这里你可以创建自己的 “pods” (个人数据存储)。你决定这个 “pods” 将被托管在哪里，谁将访问哪些数据元素以及数据将如何通过这个 pod 分享。
|
||||
基本上，[Solid][4] 是一个使用现有网络构建的平台，在这里你可以创建自己的 “pod” (个人数据存储)。你决定这个 “pod” 将被托管在哪里，谁将访问哪些数据元素以及数据将如何通过这个 pod 分享。
|
||||
|
||||
Berners-Lee 相信 Solid "将以一种全新的方式，授权个人、开发者和企业来构思、构建和寻找创新、可信和有益的应用和服务。"
|
||||
Berners-Lee 相信 Solid “将以一种全新的方式，授权个人、开发者和企业来构思、构建和寻找创新、可信和有益的应用和服务。”
|
||||
|
||||
开发人员需要将 Solid 集成进他们的应用程序和网站中。 Solid 仍在早期阶段，所以目前没有相关的应用程序。但是项目网站宣称“第一批 Solid 应用程序正在开发当中”。
|
||||
|
||||
Berners-Lee 已经创立一家名为[Inrupt][5] 的初创公司，并已从麻省理工学院休假来全职工作在 Solid，来将其”从少部分人的愿景带到多数人的现实“。
|
||||
Berners-Lee 已经创立一家名为 [Inrupt][5] 的初创公司，并已从麻省理工学院休学术假来全职工作在 Solid，来将其”从少部分人的愿景带到多数人的现实“。
|
||||
|
||||
如果你对 Solid 感兴趣，[学习如何开发应用程序][6]或者以自己的方式[给项目做贡献][7]。当然，建立和推动 Solid 的广泛采用将需要大量的努力，所以每一点的贡献都将有助于分布式网络的成功。
|
||||
如果你对 Solid 感兴趣，可以[学习如何开发应用程序][6]或者以自己的方式[给项目做贡献][7]。当然，建立和推动 Solid 的广泛采用将需要大量的努力，所以每一点的贡献都将有助于去中心化网络的成功。
|
||||
|
||||
你认为[分布式网络][8]会成为现实吗？你是如何看待分布式网络，特别是 Solid 项目的？
|
||||
你认为[去中心化网络][8]会成为现实吗？你是如何看待去中心化网络，特别是 Solid 项目的？
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -30,7 +30,7 @@ via: https://itsfoss.com/solid-decentralized-web/
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[ypingcn](https://github.com/ypingcn)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
10
scripts/badge.sh
Executable file
10
scripts/badge.sh
Executable file
@ -0,0 +1,10 @@
|
||||
#!/usr/bin/env bash
|
||||
# 重新生成badge
|
||||
set -o errexit
|
||||
|
||||
SCRIPTS_DIR=$(cd $(dirname "$0") && pwd)
|
||||
BUILD_DIR=$(cd $SCRIPTS_DIR/.. && pwd)/build
|
||||
mkdir -p ${BUILD_DIR}/badge
|
||||
for catalog in published translated translating sources;do
|
||||
${SCRIPTS_DIR}/badge/show_status.sh -s ${catalog} > ${BUILD_DIR}/badge/${catalog}.svg
|
||||
done
|
||||
92
scripts/badge/show_status.sh
Executable file
92
scripts/badge/show_status.sh
Executable file
@ -0,0 +1,92 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -e
|
||||
|
||||
function help()
|
||||
{
|
||||
cat <<EOF
|
||||
Usage: ${0##*/} [+-s} [published] [translated] [translating] [sources]
|
||||
|
||||
显示已发布、已翻译、正在翻译和待翻译的数量
|
||||
|
||||
-s 输出为svg格式
|
||||
EOF
|
||||
}
|
||||
|
||||
while getopts :s OPT; do
|
||||
case $OPT in
|
||||
s|+s)
|
||||
show_format="svg"
|
||||
;;
|
||||
*)
|
||||
help
|
||||
exit 2
|
||||
esac
|
||||
done
|
||||
shift $(( OPTIND - 1 ))
|
||||
OPTIND=1
|
||||
|
||||
declare -A catalog_comment_dict
|
||||
catalog_comment_dict=([translated]="待校对" [published]="已发布" [translating]="翻译中" [sources]="待翻译")
|
||||
|
||||
function count_files_under_dir()
|
||||
{
|
||||
local dir=$1
|
||||
local pattern=$2
|
||||
find ${dir} -name "${pattern}" -type f |wc -l
|
||||
}
|
||||
|
||||
cd "$(dirname $0)/../.." # 进入TP root
|
||||
|
||||
for catalog in "$@";do
|
||||
case "${catalog}" in
|
||||
published)
|
||||
num=$(count_files_under_dir "${catalog}" "[0-9]*.md")
|
||||
;;
|
||||
translated)
|
||||
num=$(count_files_under_dir "${catalog}" "[0-9]*.md")
|
||||
;;
|
||||
translating)
|
||||
num=$(git grep -niE "translat|fanyi|翻译" sources/*.md |awk -F ":" '{if ($2<=3) print $1}' |wc -l)
|
||||
;;
|
||||
sources)
|
||||
total=$(count_files_under_dir "${catalog}" "[0-9]*.md")
|
||||
translating_num=$(git grep -niE "translat|fanyi|翻译" sources/*.md |awk -F ":" '{if ($2<=3) print $1}' |wc -l)
|
||||
num=$((${total} - ${translating_num}))
|
||||
;;
|
||||
*)
|
||||
help
|
||||
exit 2
|
||||
esac
|
||||
|
||||
comment=${catalog_comment_dict[${catalog}]}
|
||||
if [[ "${show_format}" == "svg" ]];then
|
||||
cat <<EOF
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="120" height="20">
|
||||
<linearGradient id="b" x2="0" y2="100%">
|
||||
<stop offset="0" stop-color="#bbb" stop-opacity=".1" />
|
||||
<stop offset="1" stop-opacity=".1" />
|
||||
</linearGradient>
|
||||
<mask id="a">
|
||||
<rect width="132.53125" height="20" rx="3" fill="#fff" />
|
||||
</mask>
|
||||
<g mask="url(#a)">
|
||||
<path fill="#555" d="M0 0 h70.53125 v20 H0 z" />
|
||||
<path fill="#97CA00" d="M70.53125 0 h62.0 v20 H70.53125 z" />
|
||||
<path fill="url(#b)" d="M0 0 h132.53125 v20 H0 z" />
|
||||
</g>
|
||||
<g fill="#fff" font-family="DejaVu Sans" font-size="11">
|
||||
<text x="6" y="15" fill="#010101" fill-opacity=".3">${comment}</text>
|
||||
<text x="6" y="14">${comment}</text>
|
||||
<text x="74.53125" y="15" fill="#010101" fill-opacity=".3">${num}</text>
|
||||
<text x="74.53125" y="14">${num}</text>
|
||||
</g>
|
||||
</svg>
|
||||
EOF
|
||||
else
|
||||
cat<<EOF
|
||||
${comment}: ${num}
|
||||
EOF
|
||||
fi
|
||||
|
||||
done
|
||||
93
sources/talk/20170921 The Rise and Rise of JSON.md
Normal file
93
sources/talk/20170921 The Rise and Rise of JSON.md
Normal file
@ -0,0 +1,93 @@
|
||||
The Rise and Rise of JSON
|
||||
======
|
||||
JSON has taken over the world. Today, when any two applications communicate with each other across the internet, odds are they do so using JSON. It has been adopted by all the big players: Of the ten most popular web APIs, a list consisting mostly of APIs offered by major companies like Google, Facebook, and Twitter, only one API exposes data in XML rather than JSON. Twitter, to take an illustrative example from that list, supported XML until 2013, when it released a new version of its API that dropped XML in favor of using JSON exclusively. JSON has also been widely adopted by the programming rank and file: According to Stack Overflow, a question and answer site for programmers, more questions are now asked about JSON than about any other data interchange format.
|
||||
|
||||
![][1]
|
||||
|
||||
XML still survives in many places. It is used across the web for SVGs and for RSS and Atom feeds. When Android developers want to declare that their app requires a permission from the user, they do so in their app’s manifest, which is written in XML. XML also isn’t the only alternative to JSON—some people now use technologies like YAML or Google’s Protocol Buffers. But these are nowhere near as popular as JSON. For the time being, JSON appears to be the go-to format for communicating with other programs over the internet.
|
||||
|
||||
JSON’s dominance is surprising when you consider that as recently as 2005 the web world was salivating over the potential of “Asynchronous JavaScript and XML” and not “Asynchronous JavaScript and JSON.” It is of course possible that this had nothing to do with the relative popularity of the two formats at the time and reflects only that “AJAX” must have seemed a more appealing acronym than “AJAJ.” But even if some people were already using JSON instead of XML in 2005 (and in fact not many people were yet), one still wonders how XML’s fortunes could have declined so precipitously that a mere decade or so later “Asynchronous JavaScript and XML” has become an ironic misnomer. What happened in that decade? How did JSON supersede XML in so many applications? And who came up with this data format now depended on by engineers and systems all over the world?
|
||||
|
||||
### The Birth of JSON
|
||||
|
||||
The first JSON message was sent in April of 2001. Since this was a historically significant moment in computing, the message was sent from a computer in a Bay-Area garage. Douglas Crockford and Chip Morningstar, co-founders of a technology consulting company called State Software, had gathered in Morningstar’s garage to test out an idea.
|
||||
|
||||
Crockford and Morningstar were trying to build AJAX applications well before the term “AJAX” had been coined. Browser support for what they were attempting was not good. They wanted to pass data to their application after the initial page load, but they had not found a way to do this that would work across all the browsers they were targeting.
|
||||
|
||||
Though it’s hard to believe today, Internet Explorer represented the bleeding edge of web browsing in 2001. As early as 1999, Internet Explorer 5 supported a primordial form of XMLHttpRequest, which programmers could access using a framework called ActiveX. Crockford and Morningstar could have used this technology to fetch data for their application, but they could not have used the same solution in Netscape 4, another browser that they sought to support. So Crockford and Morningstar had to use a different system that worked in both browsers.
|
||||
|
||||
The first JSON message looked like this:
|
||||
|
||||
```
|
||||
<html><head><script>
|
||||
document.domain = 'fudco';
|
||||
parent.session.receive(
|
||||
{ to: "session", do: "test",
|
||||
text: "Hello world" }
|
||||
)
|
||||
</script></head></html>
|
||||
```
|
||||
|
||||
Only a small part of the message resembles JSON as we know it today. The message itself is actually an HTML document containing some JavaScript. The part that resembles JSON is just a JavaScript object literal being passed to a function called `receive()`.
|
||||
|
||||
Crockford and Morningstar had decided that they could abuse an HTML frame to send themselves data. They could point a frame at a URL that would return an HTML document like the one above. When the HTML was received, the JavaScript would be run, passing the object literal back to the application. This worked as long as you were careful to sidestep browser protections preventing a sub-window from accessing its parent; you can see that Crockford and Mornginstar did that by explicitly setting the document domain. (This frame-based technique, sometimes called the hidden frame technique, was commonly used in the late 90s before the widespread implementation of XMLHttpRequest.)
|
||||
|
||||
The amazing thing about the first JSON message is that it’s not obviously the first usage of a new kind of data format at all. It’s just JavaScript! In fact the idea of using JavaScript this way is so straightforward that Crockford himself has said that he wasn’t the first person to do it—he claims that somebody at Netscape was using JavaScript array literals to communicate information as early as 1996. Since the message is just JavaScript, it doesn’t require any kind of special parsing. The JavaScript interpreter can do it all.
|
||||
|
||||
The first ever JSON message actually ran afoul of the JavaScript interpreter. JavaScript reserves an enormous number of words—there are 64 reserved words as of ECMAScript 6—and Crockford and Morningstar had unwittingly used one in their message. They had used `do` as a key, but `do` is reserved. Since JavaScript has so many reserved words, Crockford decided that, rather than avoid using all those reserved words, he would just mandate that all JSON keys be quoted. A quoted key would be treated as a string by the JavaScript interpreter, meaning that reserved words could be used safely. This is why JSON keys are quoted to this day.
|
||||
|
||||
Crockford and Morningstar realized they had something that could be used in all sorts of applications. They wanted to name their format “JSML”, for JavaScript Markup Language, but found that the acronym was already being used for something called Java Speech Markup Language. So they decided to go with “JavaScript Object Notation”, or JSON. They began pitching it to clients but soon found that clients were unwilling to take a chance on an unknown technology that lacked an official specification. So Crockford decided he would write one.
|
||||
|
||||
In 2002, Crockford bought the domain [JSON.org][2] and put up the JSON grammar and an example implementation of a parser. The website is still up, though it now includes a prominent link to the JSON ECMA standard ratified in 2013. After putting up the website, Crockford did little more to promote JSON, but soon found that lots of people were submitting JSON parser implementations in all sorts of different programming languages. JSON’s lineage clearly tied it to JavaScript, but it became apparent that JSON was well-suited to data interchange between arbitrary pairs of languages.
|
||||
|
||||
### Doing AJAX Wrong
|
||||
|
||||
JSON got a big boost in 2005. That year, a web designer and developer named Jesse James Garrett coined the term “AJAX” in a blog post. He was careful to stress that AJAX wasn’t any one new technology, but rather “several technologies, each flourishing in its own right, coming together in powerful new ways.” AJAX was the name that Garrett was giving to a new approach to web application development that he had noticed gaining favor. His blog post went on to describe how developers could leverage JavaScript and XMLHttpRequest to build new kinds of applications that were more responsive and stateful than the typical web page. He pointed to Gmail and Flickr as examples of websites already relying on AJAX techniques.
|
||||
|
||||
The “X” in “AJAX” stood for XML, of course. But in a follow-up Q&A post, Garrett pointed to JSON as an entirely acceptable alternative to XML. He wrote that “XML is the most fully-developed means of getting data in and out of an AJAX client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data.”
|
||||
|
||||
Developers indeed found that they could easily use JSON to build AJAX applications and many came to prefer it to XML. And so, ironically, the interest in AJAX led to an explosion in JSON’s popularity. It was around this time that JSON drew the attention of the blogosphere.
|
||||
|
||||
In 2006, Dave Winer, a prolific blogger and the engineer behind a number of XML-based technologies such as RSS and XML-RPC, complained that JSON was reinventing XML for no good reason. Though one might think that a contest between data interchange formats would be unlikely to engender death threats, Winer wrote:
|
||||
|
||||
> No doubt I can write a routine to parse [JSON], but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now.
|
||||
|
||||
It’s easy to understand Winer’s frustration. XML has never been widely loved. Even Winer has said that he does not love XML. But XML was designed to be a system that could be used by everyone for almost anything imaginable. To that end, XML is actually a meta-language that allows you to define domain-specific languages for individual applications—RSS, the web feed technology, and SOAP (Simple Object Access Protocol) are examples. Winer felt that it was important to work toward consensus because of all the benefits a common interchange format could bring. He felt that XML’s flexibility should be able to accommodate everybody’s needs. And yet here was JSON, a format offering no benefits over XML except those enabled by throwing out the cruft that made XML so flexible.
|
||||
|
||||
Crockford saw Winer’s blog post and left a comment on it. In response to the charge that JSON was reinventing XML, Crockford wrote, “The good thing about reinventing the wheel is that you can get a round one.”
|
||||
|
||||
### JSON vs XML
|
||||
|
||||
By 2014, JSON had been officially specified by both an ECMA standard and an RFC. It had its own MIME type. JSON had made it to the big leagues.
|
||||
|
||||
Why did JSON become so much more popular than XML?
|
||||
|
||||
On [JSON.org][2], Crockford summarizes some of JSON’s advantages over XML. He writes that JSON is easier for both humans and machines to understand, since its syntax is minimal and its structure is predictable. Other bloggers have focused on XML’s verbosity and “the angle bracket tax.” Each opening tag in XML must be matched with a closing tag, meaning that an XML document contains a lot of redundant information. This can make an XML document much larger than an equivalent JSON document when uncompressed, but, perhaps more importantly, it also makes an XML document harder to read.
|
||||
|
||||
Crockford has also claimed that another enormous advantage for JSON is that JSON was designed as a data interchange format. It was meant to carry structured information between programs from the very beginning. XML, though it has been used for the same purpose, was originally designed as a document markup language. It evolved from SGML (Standard Generalized Markup Language), which in turn evolved from a markup language called Scribe, intended as a word processing system similar to LaTeX. In XML, a tag can contain what is called “mixed content,” or text with inline tags surrounding words or phrases. This recalls the image of an editor marking up a manuscript with a red or blue pen, which is arguably the central metaphor of a markup language. JSON, on the other hand, does not support a clear analogue to mixed content, but that means that its structure can be simpler. A document is best modeled as a tree, but by throwing out the document idea Crockford could limit JSON to dictionaries and arrays, the basic and familiar elements all programmers use to build their programs.
|
||||
|
||||
Finally, my own hunch is that people disliked XML because it was confusing, and it was confusing because it seemed to come in so many different flavors. At first blush, it’s not obvious where the line is between XML proper and its sub-languages like RSS, ATOM, SOAP, or SVG. The first lines of a typical XML document establish the XML version and then the particular sub-language the XML document should conform to. That is a lot of variation to account for already, especially when compared to JSON, which is so straightforward that no new version of the JSON specification is ever expected to be written. The designers of XML, in their attempt to make XML the one data interchange format to rule them all, fell victim to that classic programmer’s pitfall: over-engineering. XML was so generalized that it was hard to use for something simple.
|
||||
|
||||
In 2000, a campaign was launched to get HTML to conform to the XML standard. A specification was published for XML-compliant HTML, thereafter known as XHTML. Some browser vendors immediately started supporting the new standard, but it quickly became obvious that the vast HTML-producing public were unwilling to revise their habits. The new standard called for stricter validation of XHTML than had been the norm for HTML, but too many websites depended on HTML’s forgiving rules. By 2009, an attempt to write a second version of the XHTML standard was aborted when it became clear that the future of HTML was going to be HTML5, a standard that did not insist on XML compliance.
|
||||
|
||||
If the XHTML effort had succeeded, then maybe XML would have become the common data format that its designers hoped it would be. Imagine a world in which HTML documents and API responses had the exact same structure. In such a world, JSON might not have become as ubiquitous as it is today. But I read the failure of XHTML as a kind of moral defeat for the XML camp. If XML wasn’t the best tool for HTML, then maybe there were better tools out there for other applications also. In that world, our world, it is easy to see how a format as simple and narrowly tailored as JSON could find great success.
|
||||
|
||||
If you enjoyed this post, more like it come out every two weeks! Follow [@TwoBitHistory][3] on Twitter or subscribe to the [RSS feed][4] to make sure you know when a new post is out.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html
|
||||
|
||||
作者：[Two-Bit History][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://twobithistory.org
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://twobithistory.org/images/json.svg
|
||||
[2]: http://JSON.org
|
||||
[3]: https://twitter.com/TwoBitHistory
|
||||
[4]: https://twobithistory.org/feed.xml
|
||||
Loading…
Reference in New Issue
Block a user