Implementig a XCAP web server: Ebb and Rack?

Hi, I plan to deploy a web server to implement a XCAP service (it's basically
a web server which handles body with specific XML content). Some examples:

- The client requests a XML document (GET) so the server replies it in the
body of the 200 OK.

- The client stores a XML document (PUT) in the server, so the server
validates it and stores in a DB table.

There are a lot of web servers built in Ruby and I'm getting a bit crazy by
tryting to choose one. I've read about Ebb web server (which seems to be very
fast) and RACK (which seems to be a framework to build the application by
receiving requests from the web service, Ebb in this case).

Unfortunatelly, by reading the doc of RACK (Ebb has no doc at all) I can't
figure how to build the application:
  http://rack.rubyforge.org/doc/

RACK doc also talks about "middleware" (buff...) which annoy me even more.
Anyhow I think that what I want to achieve doesn't require more middleware.
But I would like to have some "get started" guidelines to work with RACK. For
example, a ismple example:

A web server that receive a request and replies "200 OK" if the request URL is
"/yes" and "404 Not Found" is the request URL is "/no".

Could I get some tips on how to build this simple example with Ebb and RACK?

Thanks a lot.

···

--
Iñaki Baz Castillo <ibc@aliax.net>

I've found a introduction to Rack:
  http://chneukirchen.org/blog/archive/2007/02/introducing-rack.html

···

El Jueves, 27 de Agosto de 2009, Iñaki Baz Castillo escribió:

RACK doc also talks about "middleware" (buff...) which annoy me even more.
Anyhow I think that what I want to achieve doesn't require more middleware.
But I would like to have some "get started" guidelines to work with RACK.
For example, a ismple example:

A web server that receive a request and replies "200 OK" if the request URL
is "/yes" and "404 Not Found" is the request URL is "/no".

Could I get some tips on how to build this simple example with Ebb and
RACK?

--
Iñaki Baz Castillo <ibc@aliax.net>

- The client requests a XML document (GET) so the server replies it in the
body of the 200 OK.

- The client stores a XML document (PUT) in the server, so the server
validates it and stores in a DB table.

Sounds very much like a REST architecture, which Rails (among others) is very
good at.

There are a lot of web servers built in Ruby and I'm getting a bit crazy by
tryting to choose one.

Don't.

I've read about Ebb web server (which seems to be
very fast) and RACK (which seems to be a framework to build the application
by receiving requests from the web service, Ebb in this case).

That's the point.

If you wanted to work close to the metal, you would use Rack. Your application
would then be easily portable beween Ebb, Mongrel, Thin, Passenger/modrails,
etc, without much work from you.

But if you use Rack, you shouldn't have to choose one of those other
frameworks right away, in order to develop your app. Develop the app first,
then try different webservers to see which one works best.

Unfortunatelly, by reading the doc of RACK (Ebb has no doc at all) I can't
figure how to build the application:

Rack itself is still not really friendly to work with.

If you don't want to learn Rails (which ultimately uses Rack), you could
instead try something else. Sinatra might be the simplest. But even here,
you're choosing between frameworks -- you shouldn't really have to think about
all those other layers.

What I'm getting at is, say you want to use Sinatra. You would just do:

# gem install sinatra

Then, in your application, you'd do:

require 'rubygems'
require 'sinatra'

And then you'd forget Rack, or Ebb, or any of those other things even exist,
until you need to tune your app for performance.

A web server that receive a request and replies "200 OK" if the request URL
is "/yes" and "404 Not Found" is the request URL is "/no".

Here's a simple Sinatra script:

require 'rubygems'
require 'sinatra'

get '/yes' do
  "Hello, World!\n"
end

Just run that, then try http://localhost:4567/yes, and you'll get 'Hello,
World!' with a status code of 200. Anything else, you'll get a 404.

···

On Thursday 27 August 2009 04:28:20 pm Iñaki Baz Castillo wrote: