Re: [Simpleweb-Support] simple server, mamba

[PA <pet...@gm...>]

Hi Niall,

On Mar 18, 2005, at 01:35, Niall Gallagher wrote:

> I have had a look at you implementation in LUA. Just
> wondering, you have taken a different approach on a
> few things, any ideas you think might be useful in
> Simple?

Well, the implementation itself is quite different as the underlying=20
language and VM are very much different. That said, I think that=20
conceptually they are very close. Or to put it another way, Simple is=20
very much the inspiration for LuaWeb :)

Both Simple and LuaWeb provides 3 main functionalities as I see it: an=20=

event dispatcher, a core HTTP engine and the scaffolding for an app=20
server.

Concurrent event dispatching in Lua is handled quite differently than=20
in Simple as Lua provides coroutine instead of threads:

"Non-Preemptive Multithreading"
http://www.lua.org/pil/9.4.html

The end result being somewhat similar to java.nio selectors as well as=20=

what Simple itself does: limit the number to threads while keeping=20
concurrency high nonetheless.

The HTTP engine itself is quite similar in both implementation:=20
requests, responses, services, etc. In both libraries, an HTTP engine=20
is defined as a set of services which handle a subset of the URL=20
namespace.

Finally, there is the app server scaffolding. This is perhaps where=20
Simple and LuaWeb diverge the most. But this is somewhat to be expected=20=

as everyone has their own like and dislike about how an app server=20
should behave. Even ZO=CB, while happily using Simple since the summer =
of=20
2003, has its own implementation of an app server build on top of=20
Simple itself...

Perhaps one thing which would be beneficial though, is to have the=20
Simple HTTP engine emphasize the HTTP methods themselves (e.g. GET vs=20
HEAD vs OPTIONS, etc).

For example, in LuaWeb, the default HTTP service implements HEAD in=20
terms of GET. That way all the services can handle a HEAD request=20
out-of-the-box. In contrast, each Simple services has to explicitly=20
switch between the different HTTP methods in their process() method. As=20=

an illustration, contrast the implementation of=20
simple.http.serve.FileResource and LWFileService:

http://dev.alt.textdrive.com/file/LW/LWFileService.lua

The same applies for OPTIONS which is implemented by the default=20
LWService in terms of what HTTP methods a service effectively provides.

Emphasizing the HTTP methods upfront provides a nice logical=20
distinction between what your custom service needs to do, as there is=20
no need for conditional execution (e.g. GET vs POST vs DELETE).

Most likely there are other differences here and there, but, all in=20
all, I found both library quite similar in purpose if not in execution=20=

:)

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/