WSGI 已死:WSGI 精简版万岁!(WSGI Is Dead: Long Live WSGI Lite!)

编程语言 William 328浏览 0评论

Almost a decade ago, back when I first proposed the idea of WSGI to the Web-SIG, I had a rather idealistic vision of how WSGI could be a kind of "framework dissolver".  I envisioned a future in which everything was pluggable, and there would no longer be any reason to have monolithic application frameworks, because everything could be done with libraries, middleware, and decorators.

Alas, that idealistic future didn’t come to pass.  In fact, as far back as 2007, I had already noticed it wasn’t working, and proposed an idea for a WSGI 2 protocol that would resolve the problems…  and then proceeded to do nothing for the next few years.  (Well, I’ve been doing other things, like working on setuptools, Chandler, and my own business.  I just wasn’t working on web apps or WSGI!)

大约十年前,回到我第一次向Web-SIG提出的WSGI想法的时候,那时我对WSGI有一个相当理想的认识版本——WSGI应该是一种“框架容器”。在我所设想的未来中,一切都是可插拔的,并将不会有理由有全功能的应用框架,因为一切都可以做成库、中间件和装饰器。

唉,理想主义的未来没到来过。事实上,早在2007,我已经意识到这不会实现,并提出了一个可以解决这个问题的WSGI 2 协议,之后接下来的几年里几乎再没做什么。(嗯,我一直在做其他的事情,比如在setuptools、Chandler和我自己的事情上忙活着,对Web应用或WSGI没怎么上过心!)

Anyway, last week, Armin Ronacher wrote a great article on his blog called WSGI and the Pluggable Pipe Dream, about this very topic.  If you haven’t read it, I urge you to do so, as it provides in-depth coverage of many of WSGI’s dark corners and design decisions that are not widely understood by people who weren’t involved in the original design, or who haven’t spent a lot of time working with it.

But I was a little disappointed with the end of the article, because Armin’s build-up led me to believe he had a solution to the problems of dealing with crud like start_response, write, close, and all that in WSGI middleware.  But really, his claim ended up being that even if somebody invented something better than WSGI, there would be no way to replace it, because of all the investment in the existing protocol.

然而,上周,Armin Ronacher在自己的博客中写了一篇名为“WSGI 的可插拔梦”(OSC翻译地址)的伟大文章正是关于这个话题的。如果你还没有读过它,我希望你读一下,因为它提供了对许多WSGI设计描述及细节的深入报道,那些没有参与原设计或没有在WSGI上面花很多时间的人对这些设计及细节普遍理解不深。

但我对文章的结尾有点失望,因为Armin的总结使我相信他有办法解决像start_response、write、close等所有WSGI中间层中的问题。但说真的,他最终会得到这样的结论:即使有人发明了一种比WSGI更好的协议,考虑到现协议里的已有投资,新协议依旧没有办法取代它。

So, I decided to do something about that.

CHALLENGE ACCEPTED!

Introducing WSGI Lite, WSGI’s new younger brother.

WSGI Lite is a protocol that’s basically the same thing as the "WSGI 2" calling convention I proposed four years ago, and pretty much the same as what other languages’ versions of WSGI use.  There’s no start_response, close, write, or exc_info to mess with, and I even threw in a massively improved way to manage post-request resource release and cleanup operations.

所有我觉得做些相关的事情。

CHALLENGE ACCEPTED!

引入WSGI Lite,WSGI的新的年轻兄弟。

WSGI Lite是一个协议,基本上遵从四年前我提出的所谓“WSGI 2”的约定,几乎和其他语言使用的WSGI版本一样,但没有不愿让人招惹的start_response、clost、write和exc_info,我甚至投入了一个大规模的改善方案,来管理POST请求资源释放及清理工作。

Now, if WSGI Lite were just a WSGI alternative, Armin’s article would be right: nobody would use it, because it’d be in competition with WSGI, and we’d have to basically "Shut…  Down…  Everything"  in order to replace it.

But the WSGI Lite protocol is actually backwards compatible with WSGI.  You can write code to the WSGI Lite API, and transparently interoperate with existing WSGI servers, apps, and middleware.

Which means, you don’t have to replace anything; you can just start using it, wherever it’s appropriate or useful to do so.

现在,如果WSGI Lite只是WSGI的一个替代,Armin的文章是正确的:没有人会使用它,因为它会与WSGI竞争,为替换它我们不得不“关闭任何在跑的应用”。

但WSGI Lite协议实际上是向后兼容的WSGI。你可以使用WSGI Lite的API写代码,透明地与现有的WSGI服务、应用程序及中间件完成互操作。

这意味着什么呢,你不需要更换任何东西,你可以马上开始使用它,无论这样做是否适当或有用与否。

All it takes, is two decorators: one to declare an app as being a "lite" app, and one to allow you to call standard WSGI apps using the "lite" calling protocol.  (And, as a special bonus, the decorator you use for new code can also automatically bind environment keys, session/request objects, or other cool things to your app or middleware’s keyword arguments.  It’s tres chic.)

I’m hoping that this will revitalize the "pluggable pipe dream", and make it a little less dream, a little more pipe.

So try it out, and let me know what you think.

Update: on reflection, the above article is woefully inadequate to explain the actual rationale of the WSGI Lite protocol or its implementation, so I’ve written a follow-up piece to cover that.  Check it out!

所有它需要的是两个修饰器:一个用来声明一个应用程序是“lite”版的应用程序,另一个允许你使用“lite”版的调用协议调用标准的WSGI应用。(而且作为特殊奖励,你为新代码使用的修饰器可以自动绑定环境关键字、session/request对象及做一些对你应用或中间件关键字参数相当酷的事情,这是非常漂亮的。)

我希望这将重振“可插拔的白日梦”,并让它少一点梦想,多一点实现

所以尝试它,并让我知道你所想的。

更新:反过来看,上面的文章远远不足不能说清WSGI Lite协议的原理及成就,所以我写了一篇后续文章,可以看一下!


via:oschina

转载请注明:AspxHtml学习分享网 » WSGI 已死:WSGI 精简版万岁!(WSGI Is Dead: Long Live WSGI Lite!)

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址