[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Outdated page(s) on ruby-lang.org?

Peña, Botp

10/21/2003 1:01:00 AM

sir matz@ruby-lang.org [mailto:matz@ruby-lang.org] humbly replied:

> |> 1.8 may be a newer stable version but the claim is right.
> |
> |The claim is not that 1.6.8 is *a* stable version, but *the* stable
> |version, and that 1.8.0 is only in preview.
> |
> |The link for 1.8 goes to ruby-1.8.0-preview1.tar.gz, not
> |ruby-1.8.0.tar.gz. You have to follow the mirror links to see that
> |there is a later version of 1.8.0
>
> Since all www-admins are Japanese, English pages tend to be
> slow to be updated. We are in the process of assigning
> English speaking editors.
>

sir Matz, can we try documenting technically all ruby methods/objects?
Something like unix Man. Eg, I was trying to search doc on Webrick but
cannot find any. I look on the sources, even the source do not have comments
(well they have but only very sparse. I' referring to 1.8). You have to read
the source wc is very error-prone if you're not a ruby hacker (wish I were
guy-decoux).

hope you'll take this as a constructive comment. I'd like to help but I have
to study ruby. I cannot study fast because... oh well.

> matz.

kind regards -botp

3 Answers

Gavin Sinclair

10/21/2003 7:20:00 AM

0

On Tuesday, October 21, 2003, 11:01:15 AM, Botp wrote:

> sir Matz, can we try documenting technically all ruby methods/objects?
> Something like unix Man. Eg, I was trying to search doc on Webrick but
> cannot find any. I look on the sources, even the source do not have comments
> (well they have but only very sparse. I' referring to 1.8). You have to read
> the source wc is very error-prone if you're not a ruby hacker (wish I were
> guy-decoux).

Your wish will be granted in time, Botp. But remember that "all ruby
methods/objects" is a lot of code if you mean "everything that comes
packaged with Ruby". Webrick has not been with Ruby for long (only
since 1.8) so it's not surprising that it's not well documented.

> hope you'll take this as a constructive comment. I'd like to help but I have
> to study ruby. I cannot study fast because... oh well.

I'd like you to help as well. If using Webrick is a binary decision
for you, then you'll either use it or not, and documentation will
affect that decision. If it's a hobby, then you can spend some time
getting used to it and document it as you go. Talk to me off-list
about doing this if you like. I'm happy to help you help me :)

Cheers,
Gavin


khaines

10/22/2003 8:02:00 PM

0

Could someone with some experience with webrick maybe shed some light on
something that I am wondering?

IOWA's basic architecture has the IOWA application running as a standalone
process. When the webserver receives a request that is to be handled by
the IOWA application, a connection is made to the IOWA process via either
a CGI program or (currently) a mod_ruby handler. The request is
encapsulated in a serialized object that looks and acts a lot like an
Apache::Request. The IOWA app does its thing, and returns back to its
caller (the cgi program or mod_ruby handler) the Apache::Request with http
headers and content, ready to push on back out to the browser.

This works pretty well. It allows the IOWA app full control over the HTTP
headers that are going out to the browser, and full access to the headers
that came in, and does all of that with an acceptable level of performance
(on my server hardware the typical apps/pages can be rendered at around
20/second).

Since webrick is now a standard component of Ruby, what I am wondering,
really, is exactly what webrick provides? Would it be
worthwhile/practical for me to look at changing IOWA so that webrick
provides the framework for the communications conduit?


Thanks for your thoughts,


Kirk Haines


Eric Hodel

10/22/2003 8:25:00 PM

0

Kirk Haines (khaines@enigo.com) wrote:

> IOWA's basic architecture has the IOWA application running as a standalone
> process. When the webserver receives a request that is to be handled by
> the IOWA application, a connection is made to the IOWA process via either
> a CGI program or (currently) a mod_ruby handler. The request is
> encapsulated in a serialized object that looks and acts a lot like an
> Apache::Request. The IOWA app does its thing, and returns back to its
> caller (the cgi program or mod_ruby handler) the Apache::Request with http
> headers and content, ready to push on back out to the browser.

> Since webrick is now a standard component of Ruby, what I am wondering,
> really, is exactly what webrick provides? Would it be
> worthwhile/practical for me to look at changing IOWA so that webrick
> provides the framework for the communications conduit?

Webrick provides servlet stubs and everything else, so it would be
practical, probably trivial, to port IOWA to it.

Here's what I use for Borges, all the work happens in do_GET/do_POST,
and the majority of that work is simply mapping WEBrick Request/Response
to a Borges request/response. (With a little work, I may be able
to use a webrick request/response inside Borges, I haven't looked
into it yet.)

require 'webrick'

class BorgesServer < WEBrick::HTTPServlet::AbstractServlet

attr_accessor :handler

def initialize(server, options = {})
super @handler = options[:Handler] || WADispatcher.default
end

##
# WEBrick HTTP GET handler

def do_GET(req, res)
request = WARequest.new(req.path, req.header, req.query, req.cookies)
response = @handler.handle_request(request)

res.status = response.status
res.body = response.contents

response.headers.each do |k,v|
res[k] = v
end
end

##
# WEBrick HTTP POST handler (same as GET)

alias do_POST do_GET

##
# Create a new Borges Server

def self.create(options)
options[:BindAddress] ||= '0.0.0.0'
options[:Listen] ||= [['::', 7000]]
options[:Port] ||= 7000

server = WEBrick::HTTPServer.new(options)
server.mount("/borges", BorgesServer, options)

return server
end

##
# Start a new BorgesServer with a SIGINT handler

def self.start(options = {})
server = self.create(options)
trap("INT") do server.shutdown end
server.start

return server
end

end

--
Eric Hodel - drbrain@segment7.net - http://se...
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04