« 那些日子(九) | 返回首页 | The Implementation of Lua 5.0 中译 »

写了个简易的 web server

根据昨天留下来的思路 ,我今天做了个 web server 。只用于给本地程序做配置界面用。

这个想法其实是以前用 google desktop 时明白的,gds 和 google 很多桌面软件都用浏览器做配置界面。其实就是自己做了个简易的 web server 而已。我也不需要太多,支持 GET 即可。仅监听本地端口,本质上没碰网络。windows 都不会弹安全警告。整个代码用 C 写的,才 200 来行。

做成了 lua 的一个模块,require 进来即可用,很方便 :) 再用上点 ajax 技术,操作感也不错呢。

一开始想干脆在本机架一个 kepler ,连文件服务都不需要提供,专心实现 ajax 需要的必要接口。后来失望的发现,xmlhttp request 这个玩意,居然不支持跨域请求。哦,我不该用居然这个词,人家浏览器也是为了安全性考虑的。

又加了十几行代码让我的 web server 支持获取文件的请求,其实也满简单的。


白天里同事非要用 web service 做一个,他已经实现出来了,感觉也满好。不过我有点反感 SOAP 这个东西,不想把我们游戏引擎搞的太臃肿了。明天再接着商量商量看吧。

Comments

很短的文。但基本的理解到了。
呃...云风认准的东西没有人可以说服他的,不多说了,最后总结一下我的观点 1. 浏览器界面不如客户端界面好 2. 不用浏览器界面就没有必要用HTTP通讯协议徒增复杂度
http 协议就是文本协议啊 (._.!) 我正文中写的那样,300 行 C 代码搭建出来的东西已然够用,能复杂到哪去? 我目前的程序都只听 localhost ,这样可以避免安全隐患。谈不上远程通讯。 如果爱用命令行方式,用脚本把按 HTTP 协议,把文本通过管道送进去。无非是多一个 GET 的头的区别。 反而在 windows 下,标准输入还不能 select ,监听标准输入端口不如网络接口方便。实现一个好用的命令行终端更复杂。 有浏览器快速搭建界面,又可以兼顾命令行控制的快捷,真是何乐而不为啊。
界面和主程序分离,两个进程之间通过网络互相通讯这种做法我很熟悉,事实上几年前我的项目就开始这么干了,对这一点我没有什么异议。如果只是为了远程通讯那么采用HTTP协议就意义不大,无谓的引入了额外的复杂度,效率也受影响,采用文本命令行协议更加直接有效,在没有界面之前就可以用控制台来测试程序。 至于开发效率,你如果用TCL/TK的话只要在控制台里敲几行命令就可以搭出界面来了,不过我个人更喜欢像VB/.net这样的可视化开发工具。
跨域貌似可以用jsonp的方式,豆瓣出的api就是这种。。
回复后发现云风又出现了,明白了是怎么一回事了:) 就是界面(可能是部分界面,像设置界面之类的)与逻辑分离,界面与逻辑间的通讯使用http协议,界面就可以采用html+javascript来做了,用上ajax可以提升界面质量但不支持不同域,不同服务器调用,所以有了上面的文字...
看得不是很明白用来做什么,虽然云风下面解释了.想起一个东东,second life. 我觉得3D + "浏览器"还是不错的,至少在结构上是这样的.
@analyst 直到你提及大话中使用IE的案例做比较,我才知道我前面根本没说清楚。 这两个技术方案是截然相反的。 我这几年做项目,学到的最大的一点就是:复杂度隔离。 本文说到的 web server ,解决的问题是,将界面控制的部分分离,变成网络协议去控制它。从主程序中去掉可以不需要的界面呈现部分。让界面复杂度隔离出主程序。 大话的 UI 上出的问题正在于引入了一个庞大的不受控的复杂模块(IE ),增加了更多不确认因素。 但另一方面,大话做那些也是为了开发期复杂度分离。就是把 UI 部分完全扔给另几个人做。相互之间的 bug 都不会交叉影响。 这里的重点是采用 HHTP 协议去控制程序内在的参数,会于以呈现。而不在于界面如何搭建。 如果你觉得浏览器“不伦不类”,完全可以用 .net 用 delphi vb 去做,只要遵循基于 http 的通讯协议和主程序通讯就够了。 另,我这里提的跨平台是指开发跨平台,而不指应用跨平台(虽然后者也满有用)。.net 的开发工具都是 windows 专有的,而开发人员是 linux 上工作的。 我希望每个开发人员都可以用自己最顺手的工具,在最喜欢的平台上做工具。 至于浏览器以及 html+javascript 是一个快速开发的手段。比如只需要运行时设置和改变几个参数,没有比写两行 html 代码,放一个 input 条加一个提交按钮更快速的了。打开记事本或者 vi ,几分钟就可以搞定。这段代码还可以提交到内部的 web server 上,其他人也可以立刻享用。
.net借助mono也是可以跨平台使用的。至于像TCL/TK这样的脚本语言界面库则是完全跨平台的,而且非常容易嵌入到宿主程序中。 呵呵,刚看了云风写的在大话里用IE做界面失败的案例,现在云风又回到了这条老路上去了,3D窗口+浏览器界面,多么不伦不类的工具。
javascript + HTML 的方便程度不亚于 vb .net 这些。 客户端可供选择的东西是很多,但是涉及 3d 部分,因为我们的 3d engine 是跨平台的,所以把它再给 vb, .net 这些一起工作起来就需要额外的工作。 而大量的工具都是要求有 3d 显示的。 另外 vb .net 这些都是 windows 专有开发工具。 对于我们一半人使用 linux 做主开发平台的团队来说,更不合适。 你不可以强迫用惯 windows 的人改用 linux ,同样的道理,也不可以强迫习惯在 linux 下工作的人去 windows 下工作。
用B/S的好处就是容易部署,任何平台只要有浏览器,就可以使用,但是相对于客户端程序来说缺点也是很明显的。内部使用的工具也要求跨平台,这种需求有点过分了。 客户端可供选择使用的界面快速原型开发工具实在太多了,VB, Delphi, .net, Tcl/TK等等的开发效率都非常的高。
@justit 我的需求里不完全可以用 proxy 解决。 因为提供文件服务的 server 不在本机,但是需要跨的域在 localhost 上,外部的 proxy 访问不了 localhost 。
我刚才提交留言前预览了一下然后再提交,结果出错。。。bug??? "Comment Submission Error Your comment submission failed for the following reasons: In an effort to curb malicious comment posting by abusive users, I've enabled a feature that requires a weblog commenter to wait a short amount of time before being able to post again. Please try to post your comment again in a short while. Thanks for your patience."
ajax跨域可以用写一个简单的proxy就可以了。
支持小型web server这种方法~
@analyst 用于内部用的小工具(尤其适合原本就是命令行工作的工具,例如 CTorrent),适合快速搭建原型+跨平台。
用浏览器做界面?有什么好处?
是multi-process还是用select实现的?感觉select可能会好点。
淹没在 日子 中的技术贴
建议云风放点源码出来 给大家学习学习
动手能力真是没活说...:)
弄的人们都不看技术帖了 ... hoho

Post a comment

非这个主题相关的留言请到:留言本