Rack, Camping 2.0++

[Bluebie, Jenna]

If you're going to build cookie sessions in to the core, it should  
either do the rails thing of using multiple cookies when one is not  
enough for the data, or raise a descriptive exception explaining why  
there's a problem and how switching to the database sessions thingo  
will solve that.

I totally agree with ditching the compressed version so long as there  
are new guidelines put in place as to how much camping is too much  
camping. We still need to fit it in our backpacks.

It would also be good if you continue to maintain some easy way to do  
the compression, so people who do care about size can get a smaller  
version. Someone might want to take camping with them everywhere they  
go in the form of a 3D barcode, loadable via the camera's on mobile  
phones and many computers, or maybe they've been running their website  
on a server they can only reach via TCP over Carrier Pigeon and it's  
important to them that they can upload camping.rb with the fewest  
pigeons possible.

Does Rack::Utils give us nice short easy escaping? Can we include in  
to camping in a way that they are just nice short methods?

—
Jenna

On 22/05/2008, at 5:26 AM, Magnus Holm wrote:

> ===
> 1. Camping on Rack
> ===
>
> I've just finished rewriting Camping to use Rack in the "core". I  
> got rid of
> (a little less) than 1kB in camping.rb and removed lots of un- 
> necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).
>
> bin/camping does now only provide WEBrick, Mongrel and console- 
> support and
> should only be used in development. It uses Rack::ShowExceptions to  
> catch
> error outside the app and I've also written a middleware for faking
> X-Sendfile. For production you should create a rackup-file or setup  
> Rack in
> some other way:
>
>  #!/usr/bin/env rackup
>  # Auto-detects CGI & FastCGI
>  # Start mongrel with: ./blog.ru -s mongrel -p 3301
>  require 'blog'
>  Blog.create
>  run Blog
>
> Some notes:
> * Branch: http://github.com/judofyr/camping/commits/rack
> * You have to rename camping-unabridged.rb to camping.rb in order to  
> run apps.
> * You're app is also a Rack-app  (aka respond_to?(:call))
> * I'm using Rack::Request (@request) and Rack::Response (@response)
> * Status, headers and body must be set using @status, @headers and  
> @body,
>  not @response.status, @response.headers or @response.body
> * @headers is a Rack::Utils::HeaderHash
> * @root, @input and @cookies behaves equally; @env is gone
> * You can delete cookies with @response.delete_cookie("key")
> * Set cookies with @cookies.key = ":)" or  
> @response.set_cookie("key", ":)")
> * You can also pass a Hash when you're setting cookies:
>  @cookes.key = {:value => ":)", :expires => Time.now + 3600, :path  
> => '/app'}
> * I've removed #qsp, #un and #escape. Use Rack::Utils instead
> * This should close #104, #130 and #153
>
> ===
> 2. ORM-agnostic?
> ===
>
> What about making Camping ORM-agnostic? If it's only AR which  
> requires glue,
> we can just rename camping/db.rb to camping/ar.rb - if not we have  
> to add
> camping/og.rb, camping/dm.rb, camping/sequel.rb etc too.
>
> ===
> 3. Cookie Sessions as default
> ===
>
> What do you think about using Cookie Sessions instead of database- 
> based by
> default (in camping/sessions.rb)? It's much lighter and makes it  
> simpler to
> create apps without database. It also helps making Camping ORM- 
> agnostic.
>
> I've fixed this in the cookie_session-branch (requires Rack)  
> available at
> http://github.com/judofyr/camping/commits/cookie_session (highly  
> based on
> Jenna's work)
>
> ===
> 4. Renaming camping-unabridged.rb to camping.rb?
> ===
>
> I haven't touched camping.rb at all, do we really need to prove that  
> it's a
> micro-framework? It just makes development/releasing harder. Let's  
> just forget
> about the abridged version and rename camping-unabridged.rb to  
> camping.rb!
>
> ===
> 5. Camping 2.0
> ===
>
> Here's my plan:
> * We agree on which of these four/three features we should implement
> * _why or zimbatm (or someone who really knows Camping) double-checks
>  everything and fixes any bugs.
> * Releasing 2.0 - Make lots of hype so everybody ports their apps to  
> 2.0
> * Then we'll see if any bugs appear, fixes them quickly and  
> releasing 2.1.
>
> ---
>
> This is just some proposals, the community (aka YOU) have to decide  
> what we
> should do. So what are your thoughts?
>
> ---
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list