Implementig a XCAP web server: Ebb and Rack?

Ruby
1

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.

2

El Jueves, 27 de Agosto de 2009, Iñaki Baz C. 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’ve found a introduction to Rack:
leah blogs: Introducing Rack

3

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

  • 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.