Idea: Webshare

ruby-talk
1

Hi,

Ruby has a lot of cool web frameworks. For example:

* Borges
* CGIkit
* Iowa
* Radical
* Rails
* SWS

to mention only a few :wink:

Some of them share a significat (?) number of code, like:

* Cache (LRU,...)
* Session, unique session key generation
* Request, Response classes
* WEBrick servlets
* Dispatcher
* Html-generation stuff, templates (e.g. HTTP Error templates)

How about a common basic framework, that includes all this stuff? Of course this might not work for all frameworks, but at least Iowa, SWS, CGIkit (and Borges?) should have some common pieces of code.

Webshare... sounds like Webware :wink:

I think, if it's done right, every involved project would benefit from it (of course each project is free to use this stuff or specialize).

Who's interested? Thoughts?

Regards,

   Michael

2

Hello,

Ruby has a lot of cool web frameworks. For example:

* Borges
* CGIkit
* Iowa
* Radical
* Rails
* SWS

I'm sad that Narf doesn't have mind-share anymore (www.narf-lib.org).

Some of them share a significat (?) number of code, like:

* Cache (LRU,...)
* Session, unique session key generation
* Request, Response classes
* WEBrick servlets
* Dispatcher
* Html-generation stuff, templates (e.g. HTTP Error templates)

Somethings here are HTTP interface stuff (Request, Response classes). I
mentioned the idea of using Narf like what you mention, but I think Narf
would need to be obviously great before anything like that could happen.

I've found that dispatching and templating is a matter of personal
taste; it's hard to find common ground there. Sessions are trivial to
implement, so it doesn't really bother me that those are duplicated.

Caching would be interesting to have in a library, but I'm not sure if
I'm qualified to write it.

Cheers,

Patrick

3

Forgive me if I already sent this. I don't think I did, but it's been
another long day. :slight_smile:

I would be interested in at least exploring this somewhat. I'd definitely
be interested in sharing & improving my caching class(es) and my
request/response classes.

Kirk Haines

···

On Fri, 20 Aug 2004 04:38:22 +0900, Michael Neumann wrote

Some of them share a significat (?) number of code, like:

* Cache (LRU,...)
* Session, unique session key generation
* Request, Response classes
* WEBrick servlets
* Dispatcher
* Html-generation stuff, templates (e.g. HTTP Error templates)

How about a common basic framework, that includes all this stuff? Of
course this might not work for all frameworks, but at least Iowa,
SWS, CGIkit (and Borges?) should have some common pieces of code.

4

How about a common basic framework, that includes all this stuff? Of course this might not work for all frameworks, but at least Iowa, SWS, CGIkit (and Borges?) should have some common pieces of code.

I what we need is just an upgrade of CGI.rb. There was a post about this a long time back at ruby-talk:21315. Rails would definitely like to use something like that.

···

--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

5

What kind of caching are you referring to?

Gavin

···

On Friday, August 20, 2004, 8:45:36 AM, Patrick wrote:

I've found that dispatching and templating is a matter of personal
taste; it's hard to find common ground there. Sessions are trivial to
implement, so it doesn't really bother me that those are duplicated.

Caching would be interesting to have in a library, but I'm not sure if
I'm qualified to write it.

6

Well, from my perspective, what *I* want (for Ruwiki) is a
replacement for Ruby's CGI library. All I want is something that
will give me a nice abstraction for a request. It should give me (at
a minimum) what CGI does, or more if it can (e.g., it's sitting in
front of a WEBrick server or mod_ruby or something. Now, I've
abstracted out the request/response situation in Ruwiki, but I'm not
completely pleased with the abstraction -- I may revisit it, and do
further work to make it cleaner, but I'm not against someone saying
"I have the perfect abstraction for you to use" that will work with
both WEBrick and CGI.

Note that I don't need -- and don't *want* -- HTML generation
capabilities (I use templates). I don't need -- and don't *want* --
templating (I have a perfectly good library that Dave Thomas wrote
and I enhanced). I don't need a different Wiki engine :slight_smile:

What do I need? A standard interface for requests and responses that
lets me treat various backends as if they were effectively the same.
A way of handling caching might not be bad -- but it needs to be
smart enough for me to deal with the reality that my most expensive
cost is rendering the HTML from the Wiki source, but that I have to
deal with the possiblity that changes to pages *other* than the page
I'm rendering may require that the current page cache be
invalidated. I will probably need session support; I will need
cookie support.

I can do all of this myself -- and, given time, I will. As I have
done with Diff::LCS, and will probably do with other bits and pieces
of Ruwiki, I will look at what bits can be parceled off and made
into their own libraries or are natively their own libraries as soon
as I get Ruwiki done to the point where I can examine this. If
someone offers me libraries to do this. I'd rather see multiple
small libraries that focus on individual functionality so that I can
mix and match functionality.

I have looked at Narf a couple of times... it doesn't quite do what
I need, though.

-austin

···

On Fri, 20 Aug 2004 07:45:36 +0900, Patrick May <patrick@hexane.org> wrote:

Ruby has a lot of cool web frameworks. For example:
* Borges
* CGIkit
* Iowa
* Radical
* Rails
* SWS

I'm sad that Narf doesn't have mind-share anymore (www.narf-lib.org).

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

7

Thanks for reminding me! I'd forgotten about Narf in
all the fuss over the other frameworks, but I'll have
to take another look at it :slight_smile:

Kind Regards,

Brian Wisti
http://coolnamehere.com/

···

--- Patrick May <patrick@hexane.org> wrote:

Hello,

> Ruby has a lot of cool web frameworks. For
example:
>
> * Borges
> * CGIkit
> * Iowa
> * Radical
> * Rails
> * SWS

I'm sad that Narf doesn't have mind-share anymore
(www.narf-lib.org).

[ snip ]

8

Heartily agreed.

I'd love to see several other modules as well, but some of the core CGI
function keeps getting written over and over and over.

Time to make it make sense.

···

On Sat, 2004-08-21 at 02:36 +0900, David Heinemeier Hansson wrote:

I what we need is just an upgrade of CGI.rb. There was a post about
this a long time back at ruby-talk:21315. Rails would definitely like
to use something like that.

9

Hello,

How about a common basic framework, that includes all this stuff? Of course this might not work for all frameworks, but at least Iowa, SWS, CGIkit (and Borges?) should have some common pieces of code.

I what we need is just an upgrade of CGI.rb. There was a post about this a long time back at ruby-talk:21315. Rails would definitely like to use something like that.

Narf is an upgrade of CGI.rb. I rebuilt CGI.rb, using Wakou's tests and adding tests for everything else. I felt that the maintainer of an IO libraries should support testing itself, so Narf expanded a bit.

For example, Tom Clarke added a templating library to support testing. The idea was that writing webapps is easier if you write asserts on the variables passed to the template, instead of writing asserts on the HTML.

The good thing about Narf is that not too many folks use it. So it can still be a bit of a playground for the moment. I'm open to suggestions.

To be honest, I think the api of Narf is pretty good. This stuff isn't all that complicated. I think the main thing is supporting multiple backends, so that's what I'm going to focus on.

Cheers,

Patrick

P.S. <rant> About the only cgi design suggestion I see on ruby-talk that I outright disagree with is Request / Response.

I experimented with this in Narf, and I think it is a mistake. You end up with two objects, with alot of shared implementation code, that always go together, split apart for no practical reason. I don't mind having Request / Response separated in the documentation, but splitting it in the code just adds typing. When will you ever want a request without the response? Martin Fowler has a name for this refactoring, but I don't have his book.

The Java Servlet API is not one to imitate. It's a design which solved the problem that Java was too slow to run as a CGI. Given that ruby doesn't have that limitation, I'd rather design the API that makes building web apps easy and fun.

Why bother with the API that made it possible to run web apps on a bloated os / programming language / platform / all around lemon? </rant>

···

On Friday, August 20, 2004, at 01:36 PM, David Heinemeier Hansson wrote:

10

I am playing with different assignment statements and I am using the normal cross-language terinary operator

a = a==1 ? a : -1

Is there a shorter way to cheat this? I am dealing with a Hash and I would like to perhaps do something like:

hsh = { '*' => '(*)' , 'a' => '(1){2}' }
val = "b"
a = hsh[ val ] or hsh['*'] #to give me, a = '(*)'
val = "a"
a = hsh[ val ] or hsh['*'] #to give me, a = '(1){2}'

Thanks,

Zach

11

Hello,

What do I need? A standard interface for requests and responses that
lets me treat various backends as if they were effectively the same.
A way of handling caching might not be bad -- but it needs to be
smart enough for me to deal with the reality that my most expensive
cost is rendering the HTML from the Wiki source, but that I have to
deal with the possiblity that changes to pages *other* than the page
I'm rendering may require that the current page cache be
invalidated. I will probably need session support; I will need
cookie support.

I can do all of this myself -- and, given time, I will. As I have
done with Diff::LCS, and will probably do with other bits and pieces
of Ruwiki, I will look at what bits can be parceled off and made
into their own libraries or are natively their own libraries as soon
as I get Ruwiki done to the point where I can examine this. If
someone offers me libraries to do this. I'd rather see multiple
small libraries that focus on individual functionality so that I can
mix and match functionality.

I have looked at Narf a couple of times... it doesn't quite do what
I need, though.

ok. I thought that was what I should be doing. I got distracted and wrote a testing framework to build a wiki. I'll get back to:

* supporting multiple backends (cgi, mod_ruby, fastcgi, webrick)
* improving session support

and I already have (ok, this is a little weak)

* cookie support

I think caching is pretty algorithmic, and would be more useful if it wasn't a in a web framework.

Cheers,

Patrick

···

On Thursday, August 19, 2004, at 10:02 PM, Austin Ziegler wrote:

12

Hello,

What kind of caching are you referring to?

I think that 'caching' is a pretty basic problem, and I'm sure there are known algorithms for managing caches. This is the sort of thing that I think could be implemented so that you do things like:

     def expensive_accessor( arg1, arg2, .... argN )

     end

    cache :expensive_accessor, :algorithm => :LRU

or something. I dunno. The hard part would be knowing and implementing the algorithms, which I don't know and therefore can't.

Cheers,

Patrick

···

On Thursday, August 19, 2004, at 08:47 PM, Gavin Sinclair wrote:

13

It's almost scary how the same idea can come up in different language
communities at the same time -- here's a post from to Python Web-SIG
list from a couple of weeks ago defining a draft version of of a very
simple generic web app server API:

http://mail.python.org/pipermail/web-sig/2004-August/000518.html

The author goes for an extremely minimal approach; all the proposal
includes is a standard top-level entry point method interface for web
apps, which accepts an environment hash and a callback method which
will generate an output stream when called with a status code and
headers.

IMHO, it's too little to be very useful; without standardizing
query/form parameter passing, at least, you're still going to have to
muck about in the underlying app server API for anything more complex
than "Hello, world!" Interesting reading though.

···

--
Lennon
rcoder.net

14

You know, this is one thing I definitely agree with. In Iowa, I have an
Iowa::Request that encapsulates the request. However, it actually also
encapsulates the response, and I've found it to be a very natural thing that
the same object that brings the request into the app also carries the
response back out of it.

The Iowa::Request is modeled very closely on the mod_ruby Apache::Request,
mostly because it seems like a good, effective, familiar model, and doing so
helped me avoid reimplementing the wheel.

Kirk Haines

···

On Sun, 22 Aug 2004 06:19:08 +0900, Patrick May wrote

P.S. <rant> About the only cgi design suggestion I see on ruby-talk
that I outright disagree with is Request / Response.

I experimented with this in Narf, and I think it is a mistake. You
end up with two objects, with alot of shared implementation code,
that always go together, split apart for no practical reason. I
don't mind having Request / Response separated in the documentation,
but splitting it in the code just adds typing. When will you ever
want a request without the response? Martin Fowler has a name for
this refactoring, but I don't have his book.

15

"Patrick May" <patrick@hexane.org> schrieb im Newsbeitrag
news:B73EE02E-F3B7-11D8-BFFE-000A95848050@hexane.org...

P.S. <rant> About the only cgi design suggestion I see on ruby-talk
that I outright disagree with is Request / Response.

I experimented with this in Narf, and I think it is a mistake. You end
up with two objects, with alot of shared implementation code, that
always go together, split apart for no practical reason. I don't mind
having Request / Response separated in the documentation, but splitting
it in the code just adds typing. When will you ever want a request
without the response? Martin Fowler has a name for this refactoring,
but I don't have his book.

The Java Servlet API is not one to imitate. It's a design which solved
the problem that Java was too slow to run as a CGI. Given that ruby
doesn't have that limitation, I'd rather design the API that makes
building web apps easy and fun.

Why bother with the API that made it possible to run web apps on a
bloated os / programming language / platform / all around lemon? </rant>

There are in fact good reasons in favor of the request / response split.
First of all request and response are in fact two different things, so from
that point of view it's not a bad idea to separate them. The interface of a
combined request response instance is likely to get too bloated. There are
use cases where you only need the response (say, a page that displays the
current time) and there might be others where you don't need the response
(can't think of any at the moment though, some kind of upload maybe :-)).
Another reason why I liked the separation (in Java) is that you can easily
wrap only one of them (common with filters in Java, but similar things can
be done with Ruby, too); examples are filtering of whitespace from the
response and adding default values for request parameters. If request and
response are encapsulated in a single instance this becomes much more
difficult to do - and the fun goes away. :slight_smile:

That are my 0.02 on the matter...

Kind regards

    robert

16

Patrick May wrote:

P.S. <rant> About the only cgi design suggestion I see on ruby-talk that I outright disagree with is Request / Response.

I experimented with this in Narf, and I think it is a mistake. You end up with two objects, with alot of shared implementation code

I strongly disagree. Request and response are two completely different things; that their implementations _might_ have shared code (though I can't see where) doesn't mean that they have shared data. You receive a request object that contains the request method, URL, form parameters, cookies and headers, and you create a response object that consists of the body, cookies and headers and send it back to the server; the data of both objects has nothing in common.

Example:

if request.params['password'] = 'xyz'
  response.header['Content-Type'] = 'text/plain'
  response.cookies << { 'session_id' => 'abcde' }
  response.body = 'logged in'
end

I really can't see how a combined request/response object would make any sense here.

17

As someone who thinks that a request/response is a good thing, I'll
first agree with Andreas that while they may share implementations,
they don't share data (which suggests a Request class, a Response
class, and a "Message" class). Separating request and response, to me,
is as simple as the splitting of STDIN, STDOUT, and STDERR. In theory,
I could choose to request from one computer but respond in a different
location -- why should I be restricted to responding to the person who
made the request? (Granted, I can't see why I would do such a thing,
but who knows whether such a feature would be useful?)

-austin

···

On Sun, 22 Aug 2004 06:19:08 +0900, Patrick May <patrick@hexane.org> wrote:

P.S. <rant> About the only cgi design suggestion I see on ruby-talk
that I outright disagree with is Request / Response.

I experimented with this in Narf, and I think it is a mistake. You end
up with two objects, with alot of shared implementation code, that
always go together, split apart for no practical reason. I don't mind
having Request / Response separated in the documentation, but splitting
it in the code just adds typing. When will you ever want a request
without the response? Martin Fowler has a name for this refactoring,
but I don't have his book.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

18

Time to make it make sense.

Thought's this was intersting. On Matz's blog there was this snippet:

require 'cgi'
require 'fcgi.so'
class CGI
  class Fast < CGI
    CONTINUATION =
    def Fast::new(*args)
      at_exit do
        if CONTINUATION[0]
          CONTINUATION[0].call
        end
      end
      callcc do |c|
        CONTINUATION[0] = c
      end
      fcgi = FCGI::accept
      unless fcgi CONTINUATION[0] = nil
        exit
      end
      $defout = fcgi.out super(*args)
    end
  end
end

Does that make sense? Here's what matz says about it:

<quote>
About how to make correction of the existing CGI program minimum and make it
FastCGI correspondence

Before, such a trick has been written.

  [ above code here ]

I change "require'cgi'" into "require'fcgi'" and think that remarkable CGI
will operate as it is only by rewriting "CGI.new" to "CGI::Fast.new."
</quote>

T.

19

Hello,

···

On Thursday, August 19, 2004, at 10:02 PM, Austin Ziegler wrote:

What do I need? A standard interface for requests and responses that
lets me treat various backends as if they were effectively the same.
A way of handling caching might not be bad -- but it needs to be
smart enough for me to deal with the reality that my most expensive
cost is rendering the HTML from the Wiki source, but that I have to
deal with the possiblity that changes to pages *other* than the page
I'm rendering may require that the current page cache be
invalidated. I will probably need session support; I will need
cookie support.

What's right and wrong with cookie and session support in the standard cgi.rb?

Cheers,

Patrick

20

Hi --

···

On Fri, 20 Aug 2004, Zach Dennis wrote:

I am playing with different assignment statements and I am using the
normal cross-language terinary operator

a = a==1 ? a : -1

Is there a shorter way to cheat this? I am dealing with a Hash and I
would like to perhaps do something like:

hsh = { '*' => '(*)' , 'a' => '(1){2}' }
val = "b"
a = hsh[ val ] or hsh['*'] #to give me, a = '(*)'
val = "a"
a = hsh[ val ] or hsh['*'] #to give me, a = '(1){2}'

I'm not quite following. What's not working as you'd like exactly?

David

--
David A. Black
dblack@wobblini.net