m_seki@mva.biglobe.ne.jp wrote:
>Hello, gotoyuzo.
>
>>How about this way?
>>
>> app = YourApp.new("coreStuff")
>> app.addFunnyOption("foo","bar")
>> app.addFunnyOption("alpha","gamma")
>> app.setZoption("gamma")
>> mount("/z", YourHandler, app)
>>
>
>I did so and wrote the application serveer.
>
>I had misunderstanding at first. WEBrick is not application server
>but Web server toolkit.
>
The distinction is very minor in my mind. Can some actually give me a
firm defintion? I mean, Apache is called a web-server, but it is used
all the time to "server applications".
>Servlet model of WEBrick is not it of Java.
>
No, but so far, it has seemed fairl close to that. I do not advocate
copying Java blindly, but learning from their experience is a good idea.
>WEBrick's servlet model
>is the simple thing which associates and invokes URL and an object.
>
Much like Java's started out as, I think. Although they've added a lot
to it, at its core, thats what it does.
>
>I understand that AbstractServlet of WEBrick is a context generated
>for every request. We can write the application server (e.g. session
>management, some containers) using this primitive which WEBrick provide.
>
What I'm trying to do, is develop low-volume web applications. In doing
this, because I'm dislike most of the other choices I see, I'm growing
my own framework based on my experiences with Java tools. Now, as it
happens, WEBrick seems to have done the worst of the "grunt work", in
providing an interface to the HTTP request, so I want to use it. If I'm
going to use it, I'm going to suggest changes (it's my nature). There
are capabilities that I will *need*, and changes that I will want. I
have *no* desire to "fork" WEBrick. The issue of initialization is not
a show-stopper, but, I also don't see that there is any downside to
supporting my solution in conjunction with what is already there.