==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
Hi Magnus, On May 21, 2008, at 12:26 PM, Magnus Holm wrote:> This is just some proposals, the community (aka YOU) have to decide > what we > should do. So what are your thoughts? >Awesome work! I say go for it. :-) -enp
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
Impressive work. On Wed, May 21, 2008 at 12:26 PM, Magnus Holm <judofyr at gmail.com> 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. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080521/3606b101/attachment-0001.html>
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
> 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
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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
Magnus, On Thu, May 22, 2008 at 2:56 PM, Magnus Holm <judofyr at gmail.com> 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).Cool, great work. The changes required by the apps are simple to accomplish.> ==> 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.Interesting idea, not in the top of my list but I must confess Merb has bring DataMapper and Sequel to my attention. Being able to play with them easier in Camping would be interesting.> ==> 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.We discussed it and tried with our new Raisl 2 based applications. It works.> ==> 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. In any project keeping unnecessary artifacts is not a good practice, their maintenance drag resources form the development of the real working ones.> ==> 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.Sounds good. -- An?bal Rojas http://hasmanydevelopers.com http://rubycorner.com http://anibal.rojas.com> --- > > 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 >-- An?bal
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?
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
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 aredridel at nbtsc.org
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 <why at whytheluckystiff.net> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
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 <why at whytheluckystiff.net> > 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > > -- > Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
On May 22, 2008, at 8:01 PM, 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.I personally think that the esthetic properties of obfuscated source is what attracts quite a few people to the framework. I would really like to see it maintained as the primary distribution format. Manfred
I agree. The obfuscation could probably be automated somehow with ParseTree and ruby2ruby...I''m not entirely sure. It''d be fun to toy with though. --Jeremy On Thu, May 22, 2008 at 2:44 PM, Manfred Stienstra <manfred at gmail.com> wrote:> > On May 22, 2008, at 8:01 PM, 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. > > I personally think that the esthetic properties of obfuscated source is what > attracts quite a few people to the framework. I would really like to see it > maintained as the primary distribution format. > > Manfred > _______________________________________________ > Camping-list mailing list > Camping-list at 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
2008/5/22 Ernest Prabhakar <ernest.prabhakar at gmail.com>:> So, it sounds like there''s a few options: > > a) Automate the creation of the obfuscated version from the unabridged > versionLast time I checked, Ruby2Ruby didn''t recognize all camping constructs but it might be better now.> b) Tweak the system to run from "camping-unabridged.rb" (or a short name > thereof, e.g. "campsrc")bin/camping could easily be tweaked to add a --unabridged command-line flag> c) Make the obfusc version "camping4k", and make camping-unabridged.rb the > default camping.rbUgh !
The problem is that almost all app require ''camping'' and when bin/camping require ''camping-unabridged'' things gets pretty messy. (I just realized that bin/camping could monkey-patch require such that when the --unabridged-flag is set it require ''camping-unabridged'' instead of ''camping''. But that''s *really* dirty!) On Fri, May 23, 2008 at 12:07 PM, zimbatm <zimbatm at oree.ch> wrote:> 2008/5/22 Ernest Prabhakar <ernest.prabhakar at gmail.com>: >> So, it sounds like there''s a few options: >> >> a) Automate the creation of the obfuscated version from the unabridged >> version > > Last time I checked, Ruby2Ruby didn''t recognize all camping constructs > but it might be better now. > >> b) Tweak the system to run from "camping-unabridged.rb" (or a short name >> thereof, e.g. "campsrc") > > bin/camping could easily be tweaked to add a --unabridged command-line flag > >> c) Make the obfusc version "camping4k", and make camping-unabridged.rb the >> default camping.rb > > Ugh ! > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
> 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 ?
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 <zimbatm at oree.ch> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/963309b4/attachment-0001.html>
2008/5/22 _why <why at whytheluckystiff.net>:> 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 ? :)
> How is camping.rb created from camping-unabridged.rb? By hand?Err.. yes. This is a kind of art you know ?
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 <zimbatm at oree.ch> wrote:> 2008/5/22 _why <why at whytheluckystiff.net>: >> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
Does being implemented on top of Rack mean that Camping will get the concurrency described on pages 17..21 of http://yeahnah.org/files/rack-presentation-oct-07.pdf ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/24601934/attachment.html>
2008/5/23 Magnus Holm <judofyr at gmail.com>:> 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.
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 <zimbatm at oree.ch> wrote:> 2008/5/23 Magnus Holm <judofyr at gmail.com>: >> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
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 <judofyr at gmail.com> 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 <zimbatm at oree.ch> wrote: >> 2008/5/23 Magnus Holm <judofyr at gmail.com>: >>> 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > > -- > Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at 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
"Magnus Holm" <judofyr at gmail.com> 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 <chneukirchen at gmail.com> http://chneukirchen.org
Just wanted to comment a bit more : 2008/5/21 Magnus Holm <judofyr at gmail.com>:> 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 insteadNot 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.
Hi Z, On May 25, 2008, at 5:47 AM, zimbatm wrote:>> 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.I think that''s a great suggestion! -- Ernie P.
2008/5/25 Ernest Prabhakar <ernest.prabhakar at gmail.com>:> Hi Z, > > On May 25, 2008, at 5:47 AM, zimbatm wrote: > >>> 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. > > I think that''s a great suggestion!It''s now on my branch, but I named it camping-shortshort.rb http://github.com/zimbatm/camping/tree/master
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
2008/5/26 _why <why at whytheluckystiff.net>:> 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.