设计 EWGI 兼容性

发布于 2024-08-02 00:18:30 字数 504 浏览 2 评论 0原文

我试图了解如何设计中间件以实现 EWGI 兼容性。 鉴于目前还没有符合 EWGI 的 Web 服务器,我只能征求您的意见。

如果我理解规范。 正确的是,中间件接收 #ewgi_context{} 记录作为输入,并返回相同类型的另一条记录。

问题是,中间件是否会像 django,或者它应该递归地调用其余的中间件吗?

另外,是否有任何建议的方法让中间件通知其余中间件其结果应该是最终响应? (例如,文件服务中间件命中文件,因此没有必要调用视图中间件)。 由于我的视图结果是上下文记录,其余中间件(或服务器)应该如何确定它是最终响应?

I'm trying to understand how one should design middlewares for EWGI compatibility. Given that there is no EWGI compliant web server yet, I can only ask for your opinion.

If I understand the spec. correctly, a middleware receives an #ewgi_context{} record as input, and returns another record of the same type.

Question is, is the middleware going to be called twice as in django, or is it supposed to call the rest of the middlewares on its own recursively?

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response? (e.g. the file-serving middleware hit a file, so there is no point calling the view middleware). As the result of my view is a context record, how should the rest of the middlewares (or the server) figure out it is the final response?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

紫竹語嫣☆ 2024-08-09 00:18:30

鉴于目前还没有符合 EWGI 标准的 Web 服务器,我只能征求您的意见

没有必要存在符合 EWGI 的 Web 服务器,因为 EWGI 的作用是统一对不同 Web 服务器的访问。 这就是EWGI的核心思想。

另一方面,如果您的意思是“符合 EWGI 的 Web 框架”,那么实际上有两个(或更多?)支持 EWGI 的 Web 框架。 它们是 Erlang Web 和 BeepBeep。

或者它应该递归地调用其余的中间件吗?

中间件应该以递归方式相互调用,因此中间件的作用是决定下一步做什么。

此外,中间件是否有任何建议的方法来通知其余中间件其结果应该是最终响应

要回答你的最后一个问题,我认为因为中间件递归地相互调用,所以实现这一点的最简单方法不是如果答案是最终的,则调用其他中间件,并将#ewgi_context{}记录返回到ewgi层。

Given that there is no EWGI compliant web server yet, I can only ask for your opinion

There's no need EWGI compliant web server to exist because it's the EWGI's role to unify the access to and from different web server. That's the core idea of EWGI.

On the other hand if you meant "EWGI compliant web framework", there actually are two (or more?) web frameworks that supports EWGI. These are Erlang Web and BeepBeep.

or is it supposed to call the rest of the middlewares on its own recursively?

The middlewares are supposed to call each other in a recursive manner, so it's the middleware's role to decide what to do next.

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response

To answer your last question, I think that because middlewares call each other recursively the simplest way to achieve this would be not to call other middlewares if the answer is final, and return #ewgi_context{} record to the ewgi layer.

荒岛晴空 2024-08-09 00:18:30

中间件可以根据情况使用迭代或递归方法。

迭代方法的示例如下:

http://groups.google.com/ group/ewgi/browse_thread/thread/f9042018cb27baa3

其他简单示例位于 ewgi_examples

一般来说,我更喜欢迭代方法,但如果您有一个依赖于其他中间件的中间件,则递归方法可能更好。

此外,中间件是否有任何建议的方法来通知其余中间件其结果应该是最终响应? (例如,文件服务中间件命中文件,因此没有必要调用视图中间件)。 由于我的视图结果是上下文记录,其余中间件(或服务器)应该如何确定它是最终响应?

没有建议的方法。 如果您使用递归方法作为疯狂的答案,您只需要返回 ewgi_context。 在迭代方法中,视图或视图调用者可以检查响应正文和标头是否在 ewgi_context 中设置,并相应地决定要做什么。

一般来说,我认为 ewgi 是用于网络的 unix 管道。 每个中间件都会收到请求和响应(类似于管道中的 stdin 和 stdout),其工作是修改上下文(如果需要)并返回它。

希望这可以帮助。

Middlewares can use both the iterative or the recursive approach depending on the situation.

An examples of the iterative approach is:

http://groups.google.com/group/ewgi/browse_thread/thread/f9042018cb27baa3

Other simple examples are in ewgi_examples

In general I prefer the iterative approach, but if you you have a middleware that depends on others the recursive approach is probably better.

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response? (e.g. the file-serving middleware hit a file, so there is no point calling the view middleware). As the result of my view is a context record, how should the rest of the middlewares (or the server) figure out it is the final response?

There's no proposed way. Ifyou use the recursive approach as insane answered you only need to return the ewgi_context. In the iterative approach the view, or the view caller, could check to see if the response body and headers are set in the ewgi_context and decide what to do accordingly.

In general I think of ewgi as unix pipes for the web. Each middleware get a request and response (similar to stdin and stdout in pipes) does its job modifying the context (if needed) and returns it.

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文