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@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
