Re: Rack, Camping 2.0++

2008-05-25 Thread Christian Neukirchen
Magnus Holm [EMAIL PROTECTED] writes:

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

Yay!

Please tell me when rack/adapters/camping.rb can be removed.

-- 
Christian Neukirchen  [EMAIL PROTECTED]  http://chneukirchen.org
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-25 Thread zimbatm
Just wanted to comment a bit more :

2008/5/21 Magnus Holm [EMAIL PROTECTED]:
 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).

This is good ! I believe lib/camping/server.rb could be merged to
bin/camping since it's not really reusable.

 * I've removed #qsp, #un and #escape. Use Rack::Utils instead

Not sure if this is handy but let's see it in real-world usage

 ===
 2. ORM-agnostic?
 ===

I don't mind ORM.

 ===
 3. Cookie Sessions as default
 ===

Don't use sessions :)

 ===
 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!

This is not that hard to do. Maybe I should add some shortening tricks document.
I propose platterizing to be done only before release.

The short version should live in the camping-mural.rb file, like the
long version lives in camping-unabridged.rb . `rake release` and `rake
devel` symlink or symlink those files to camping.rb. This should avoid
having to move things around constantly.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-25 Thread _why
On Sun, May 25, 2008 at 02:47:39PM +0200, zimbatm wrote:
 This is not that hard to do. Maybe I should add some shortening tricks 
 document.
 I propose platterizing to be done only before release.

No, let's not have rules.  I don't feel comfortable with having
coding standards or any protocol on Camping.  The point of Camping
is to have very ugly, tricky code that goes against all the rules that
people make for beautiful code these days.  To show that ugly code
can do beautiful things, maybe.

I don't want to demonize anyone here, I just want to express the
ideas that make Camping different.  Camping's personality is 80x50.
It is like the little gears of a watch that are all meshed together
into a tight little mind-bending machine.  The challenge of Camping
isn't to figure out how to automate obfuscation.  The challenge is
to bring new tricks into the code that push Ruby's parser and make
everyone look twice.  Not all code needs to be a factory, some of
it can just be origami.

_why
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-25 Thread zimbatm
2008/5/26 _why [EMAIL PROTECTED]:
 On Sun, May 25, 2008 at 02:47:39PM +0200, zimbatm wrote:
 This is not that hard to do. Maybe I should add some shortening tricks 
 document.
 I propose platterizing to be done only before release.

 No, let's not have rules.  I don't feel comfortable with having
 coding standards or any protocol on Camping.  The point of Camping
 is to have very ugly, tricky code that goes against all the rules that
 people make for beautiful code these days.  To show that ugly code
 can do beautiful things, maybe.

No ! No rules ! I was proposing to write the parchment of the grand
masters of obfuscation, giving the secret of ruby parsing intricacies
to the surviving generations of mainstream railzors. Or maybe should
it be kept away of the rubinius spec-writing minions ? I don't know.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-24 Thread Magnus Holm
I don't want to be the leader. I just want to contribute to one of the sweetest
framework that exists in the Rubyverse!

I'm going to contribute with what I can, and I suck at writing documentation and
I have no intention to learn RDoc (ATM, maybe another day).

(I still think that _why is the true leader of Camping.)

On Sat, May 24, 2008 at 1:28 AM, zimbatm [EMAIL PROTECTED] wrote:
 2008/5/23 Magnus Holm [EMAIL PROTECTED]:
 So should I just merge/rebase everything to my master, so _why can merge
 it into his? Some more notes:

 * camping/db.rb - camping/ar.rb
 * camping/session.rb - camping/ar/session.rb
 * CookieSession - camping/session.rb

 The documentation and the names (Camping::Session, Camping::ARSession?)
 needs some fixing. I'll let the leader decide :-)

 You are the leader now :)

 If I where you, I'd take some time checking the documentation
 generates well. Last time I checked, it was a mess.
 ___
 Camping-list mailing list
 Camping-list@rubyforge.org
 http://rubyforge.org/mailman/listinfo/camping-list




-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-24 Thread Jeremy McAnally
If you can point to areas to document or changes you are making that
need documentation, I'd be happy to write it for you.

--Jeremy

On Sat, May 24, 2008 at 12:51 PM, Magnus Holm [EMAIL PROTECTED] wrote:
 I don't want to be the leader. I just want to contribute to one of the 
 sweetest
 framework that exists in the Rubyverse!

 I'm going to contribute with what I can, and I suck at writing documentation 
 and
 I have no intention to learn RDoc (ATM, maybe another day).

 (I still think that _why is the true leader of Camping.)

 On Sat, May 24, 2008 at 1:28 AM, zimbatm [EMAIL PROTECTED] wrote:
 2008/5/23 Magnus Holm [EMAIL PROTECTED]:
 So should I just merge/rebase everything to my master, so _why can merge
 it into his? Some more notes:

 * camping/db.rb - camping/ar.rb
 * camping/session.rb - camping/ar/session.rb
 * CookieSession - camping/session.rb

 The documentation and the names (Camping::Session, Camping::ARSession?)
 needs some fixing. I'll let the leader decide :-)

 You are the leader now :)

 If I where you, I'd take some time checking the documentation
 generates well. Last time I checked, it was a mess.
 ___
 Camping-list mailing list
 Camping-list@rubyforge.org
 http://rubyforge.org/mailman/listinfo/camping-list




 --
 Magnus Holm
 ___
 Camping-list mailing list
 Camping-list@rubyforge.org
 http://rubyforge.org/mailman/listinfo/camping-list




-- 
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: obfuscation Re: Rack, Camping 2.0++

2008-05-23 Thread zimbatm
 The problem is that almost all app require 'camping' and when bin/camping
 require 'camping-unabridged' things gets pretty messy.

Right, didn't thought about that.. well then we have to come up with a
Ruby2Ruby version, isn't it ?
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: obfuscation Re: Rack, Camping 2.0++

2008-05-23 Thread Eric Mill
How is camping.rb created from camping-unabridged.rb?  By hand?  If that's
the case, you can't expect the compressed camping.rb to be maintained once
more than _why and zimbatm start wanting to contribute, you know?  If it can
be done by script, then by all means let's do that and include that script
in the repository.

-- Eric

On Fri, May 23, 2008 at 9:18 AM, zimbatm [EMAIL PROTECTED] wrote:

  The problem is that almost all app require 'camping' and when bin/camping
  require 'camping-unabridged' things gets pretty messy.

 Right, didn't thought about that.. well then we have to come up with a
 Ruby2Ruby version, isn't it ?
 ___
 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

Re: obfuscation Re: Rack, Camping 2.0++

2008-05-23 Thread zimbatm
 How is camping.rb created from camping-unabridged.rb?  By hand?
Err.. yes. This is a kind of art you know ?
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-23 Thread zimbatm
2008/5/22 _why [EMAIL PROTECTED]:
 Splendid!  If we can say Camping, the 3K Microframework, then I
 think we will really have a reason to bump the big number.  I'll wait
 for a reaction from zimbatm, but I am euphoric about these changes.

Wasn't the one who codes who leads ? :)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-23 Thread Magnus Holm
So should I just merge/rebase everything to my master, so _why can merge
it into his? Some more notes:

* camping/db.rb - camping/ar.rb
* camping/session.rb - camping/ar/session.rb
* CookieSession - camping/session.rb

The documentation and the names (Camping::Session, Camping::ARSession?)
needs some fixing. I'll let the leader decide :-)

On Fri, May 23, 2008 at 11:18 PM, zimbatm [EMAIL PROTECTED] wrote:
 2008/5/22 _why [EMAIL PROTECTED]:
 Splendid!  If we can say Camping, the 3K Microframework, then I
 think we will really have a reason to bump the big number.  I'll wait
 for a reaction from zimbatm, but I am euphoric about these changes.

 Wasn't the one who codes who leads ? :)
 ___
 Camping-list mailing list
 Camping-list@rubyforge.org
 http://rubyforge.org/mailman/listinfo/camping-list




-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-23 Thread zimbatm
2008/5/23 Magnus Holm [EMAIL PROTECTED]:
 So should I just merge/rebase everything to my master, so _why can merge
 it into his? Some more notes:

 * camping/db.rb - camping/ar.rb
 * camping/session.rb - camping/ar/session.rb
 * CookieSession - camping/session.rb

 The documentation and the names (Camping::Session, Camping::ARSession?)
 needs some fixing. I'll let the leader decide :-)

You are the leader now :)

If I where you, I'd take some time checking the documentation
generates well. Last time I checked, it was a mess.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread _why
On Wed, May 21, 2008 at 09:26:52PM +0200, Magnus Holm wrote:
 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).

Splendid!  If we can say Camping, the 3K Microframework, then I
think we will really have a reason to bump the big number.  I'll wait
for a reaction from zimbatm, but I am euphoric about these changes.

_why
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Magnus Holm
 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.

Cookie Sessions: I think we should simply raise an error when the data is
larger than 4kB. Something is wrong when the cookie is larger than the
framework you're using.

 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.

Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's just me.  
;-)

It's alright for me to keep the compressed version, but can it live under
camping-compressed.rb (or something like that) and have the real version
under camping.rb?

 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?

Rack::Utils gives us nice short easy escaping through Rack::Utils.escape and
Rack::Utils.unescape. Creating helper-methods will just cost bytes...

 As long as you organize the code such that it's easy to switch between
 session storage schemes, I think this is fine.

I've created a branch (orm_agnostic) where I've moved db.rb - ar.rb and
session.rb - ar/session.rb so you can plug in whatever you want.

--
Right now I have spread the code around three branches (rack, cookie_session
and orm_agnostic). Just tell me which we need, and I'll merge/rebase them to
the master for easy merging with why's repo (so you guys can continue to hack
with it).

Oh, and the documentation of session needs some cleanup, but I suck at
documentation so I'll leave it to you :-)
-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Bluebie, Jenna
I really think shorter escaping methods are important, see if you  
can't include Rack::Utils or something

Aside from that, it all sounds yummy!


On 22/05/2008, at 8:32 PM, Magnus Holm wrote:

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.


Cookie Sessions: I think we should simply raise an error when the  
data is

larger than 4kB. Something is wrong when the cookie is larger than the
framework you're using.


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.


Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's  
just me.  ;-)


It's alright for me to keep the compressed version, but can it live  
under
camping-compressed.rb (or something like that) and have the real  
version

under camping.rb?

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?


Rack::Utils gives us nice short easy escaping through  
Rack::Utils.escape and

Rack::Utils.unescape. Creating helper-methods will just cost bytes...

As long as you organize the code such that it's easy to switch  
between

session storage schemes, I think this is fine.


I've created a branch (orm_agnostic) where I've moved db.rb - ar.rb  
and

session.rb - ar/session.rb so you can plug in whatever you want.

--
Right now I have spread the code around three branches (rack,  
cookie_session
and orm_agnostic). Just tell me which we need, and I'll merge/rebase  
them to
the master for easy merging with why's repo (so you guys can  
continue to hack

with it).

Oh, and the documentation of session needs some cleanup, but I suck at
documentation so I'll leave it to you :-)
--
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


Re: Rack, Camping 2.0++

2008-05-22 Thread ironald

Camping.goes :Forward
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Jerry West

Excellent work; IMHO this makes camping a viable contender again!

+1 to your 2.0/2.1 plan

Jerry

Magnus Holm wrote:

===
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?

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread _why
On Fri, May 23, 2008 at 07:27:18AM +1930, Aníbal Rojas wrote:
  ===
  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!
 
 Keeping Camping away from the bloat goes far beyond an arbitrary weight limit.
 It is a nice way to promote Camping. It is catchy saying In Less then
 4K, period.

Instead of saying the obfuscation just makes development/releasing harder,
try saying obfuscation just makes flippancy/esotericism easier.

_why
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Aria Stewart


On May 22, 2008, at 12:38 AM, _why wrote:


On Wed, May 21, 2008 at 09:26:52PM +0200, Magnus Holm wrote:
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).


Splendid!  If we can say Camping, the 3K Microframework, then I
think we will really have a reason to bump the big number.  I'll wait
for a reaction from zimbatm, but I am euphoric about these changes.



Oh, that's wonderful! I really like it!

Aria Stewart
[EMAIL PROTECTED]



___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Magnus Holm
I must agree that the obfuscation is really impressive (specially in a
presentation
where you can include the full source on one slide). I just don't like
to touch it.
And unfortunately it doesn't evolve by itself.

I'm just tired of renaming camping-unabridged.rb to camping.rb in order to test
the apps, and then back again when I commit stuff.

I'll be perfectly fine if someone else creates the obfuscated version :-)

On Thu, May 22, 2008 at 5:50 PM, _why [EMAIL PROTECTED] wrote:
 On Fri, May 23, 2008 at 07:27:18AM +1930, Aníbal Rojas wrote:
  ===
  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!

 Keeping Camping away from the bloat goes far beyond an arbitrary weight 
 limit.
 It is a nice way to promote Camping. It is catchy saying In Less then
 4K, period.

 Instead of saying the obfuscation just makes development/releasing harder,
 try saying obfuscation just makes flippancy/esotericism easier.

 _why
 ___
 Camping-list mailing list
 Camping-list@rubyforge.org
 http://rubyforge.org/mailman/listinfo/camping-list




-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

obfuscation Re: Rack, Camping 2.0++

2008-05-22 Thread Ernest Prabhakar

Hi Magnus,

On May 22, 2008, at 11:01 AM, Magnus Holm wrote:

I must agree that the obfuscation is really impressive (specially in a
presentation where you can include the full source on one slide). I  
just don't like

to touch it.
And unfortunately it doesn't evolve by itself.

I'm just tired of renaming camping-unabridged.rb to camping.rb in  
order to test

the apps, and then back again when I commit stuff.


I'll be perfectly fine if someone else creates the obfuscated  
version :-)


So, it sounds like there's a few options:

a) Automate the creation of the obfuscated version from the unabridged  
version


b) Tweak the system to run from camping-unabridged.rb (or a short  
name thereof, e.g. campsrc)


c) Make the obfusc version camping4k, and make camping-unabridged.rb  
the default camping.rb


Any of those seem viable?

-- Ernie P. 






On Thu, May 22, 2008 at 5:50 PM, _why [EMAIL PROTECTED]  
wrote:

On Fri, May 23, 2008 at 07:27:18AM +1930, Aníbal Rojas wrote:

===
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!


Keeping Camping away from the bloat goes far beyond an arbitrary  
weight limit.
It is a nice way to promote Camping. It is catchy saying In Less  
then

4K, period.


Instead of saying the obfuscation just makes development/releasing  
harder,

try saying obfuscation just makes flippancy/esotericism easier.

_why
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list





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


Re: Rack, Camping 2.0++

2008-05-21 Thread John Beppu
Impressive work.

On Wed, May 21, 2008 at 12:26 PM, Magnus Holm [EMAIL PROTECTED] 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


These API changes sound reasonable to me.



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


Fine w/ me.



 ===
 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)


As long as you organize the code such that it's easy to switch between
session storage schemes, I think this is fine.

===
 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!


Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's just
me.  ;-)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list