大多数 Erlang 应用程序（例如 MochiWeb、Riak、RabbitMQ、Zotonic、ejabberd 和 CouchDB）都是 OTP 应用程序吗？
刚刚开始阅读 Francesco Cesarini 撰写的伟大 Erlang 著作中的 OTP 章节。大多数 Erlang 应用程序（例如 MochiWeb、Riak、RabbitMQ、Zotonic、ejabberd 和 CouchDB）都是 OTP 应用程序吗？
Just started reading the OTP chapter on the great Erlang book by Francesco Cesarini. Are most Erlang applications such as MochiWeb, Riak, RabbitMQ, Zotonic, ejabberd and CouchDB OTP applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CouchDB 存在很多问题，但 Cloudant 发布的最新来源显示 CouchDB 位于 rebar 中，因此它必须符合 otp 要求。
Riak - 相同，在 rebar 上（顺便说一句，rebar 和 riak 的开发人员相同）。顺便说一句2。这是一个写得非常好的应用程序，是学习良好实践的好地方。
Zotonic 源代码看起来有点混乱。我可以看到“应用程序”等，但目录结构看起来不像任何正确的 OTP 节点。顺便提一句。甚至许可证也没有添加在所有模块的顶部：？
ejabberd 充满了支持和应用程序，但它也有一些有趣的；）设计选择，所以也许不要在这个例子中学习 Erlang。
CouchDB had lot of problems with that but the newest sources published by Cloudant show CouchDB in rebar, so it must be otp compliant.
Riak - the same, on rebar (btw. the same devs rebar and riak). Btw2. it is very nicely written app, good place to learn good practices.
Zotonic source code looks like mess a little bit. I can see there 'application' etc. but directory structure do not look like any proper OTP node. Btw. even Licence is not added on the top of all modules :?
ejabberd is full of sups and apps, but it has also some interesting;) design choices, so maybe do not learn Erlang on this example.
Hibari 数据库应用程序绝对是基于 OTP 的。服务器分为几个 OTP 应用程序，包括一个用于管理配置和日志记录的小应用程序 (gmt)、一个用于服务器本身的大应用程序 (gdss)、一个用于本机 Erlang 客户端的小应用程序 (gdss_client)，以及每个应用程序的单独 OTP 应用程序服务器端协议处理程序（例如 JSON-RPC、UBF、EBF/BERT）。
有时一张图片至少值几百个字。我从 Erlang“appmon”（应用程序监视器）应用程序中获取了一些屏幕截图，其中显示了主管和工作进程树。抱歉，协议处理程序应用程序未显示在图像 #01 中，但如果我在捕获图像时运行它们，它们就会显示。
链接位于：OTP 'appmon' 屏幕截图
-斯科特
The Hibari database app is definitely OTP-based. The server is broken into several OTP apps, including a small one for managing config and logging (gmt), a big one for the server itself (gdss), a small one for native Erlang clients (gdss_client), and separate OTP apps for each of the server-side protocol handlers (e.g. JSON-RPC, UBF, EBF/BERT).
Sometimes a picture is worth at least a few hundred words. I've got some screen captures from the Erlang "appmon" (application monitor) app that shows the supervisor-and-worker process tree. Sorry, the protocol handler apps aren't shown in image #01, but they would be if I had had them running when I captured the image.
The link is here: OTP 'appmon' screen shots
-Scott
MochiWeb 遵循基本的 OTP 设计原则：它利用 supervisor(3) 重新启动崩溃进程的行为（模块 mochiweb_sup.erl) 和 gen_server(3) 行为。然而，它实现了许多例程来处理数据，例如在
mochinum.erl中找到的用于更快的浮点数序列化和mochijson[2].erl中的例程来处理 JSON 等mochiweb 的坏处（我已经说清楚了为什么 此处）恕我直言，它使用了有问题且官方未记录（自 2003 年以来！）的技术 模块参数化（模块
mochiweb_request.erl，注意-module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]).中文件头）。这同样适用于另一个 Erlang HTTP 库 misultin (misultin_req.erl）。如果我错了请纠正我。
MochiWeb follows basic OTP Design Principles: it utilizes supervisor(3) behaviour to restart crashed processes (module mochiweb_sup.erl), and gen_server(3) behaviour. However it implements many routines to process data, such as ones found in
mochinum.erlfor faster floating point numbers serialization andmochijson[2].erlto process JSON etc.The bad thing with mochiweb (I made it clear why here) IMHO is that it uses questionable and officially undocumented (since 2003!) technique of modules parameterizing (module
mochiweb_request.erl, notice-module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]).in the head of the file). The same applies to another Erlang HTTP-library misultin (misultin_req.erl).Correct me if I'm wrong.