From zimbatm at oree.ch  Sun Sep 23 15:58:11 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Sun, 23 Sep 2007 21:58:11 +0200
Subject: Next camping release
Message-ID: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>

Dear camping users,

having been contacted by Julian Tarkhanov, I am willing to prepare the
next camping release. _why has given me his friendly approval, with
the reserve that camping.rb should be lower than 4k. He also told me
that he wanted to remove the ActiveSupport and Markaby dependencies.

I am writing here to get the users input so that I don't do any
mistake. So far, my plans are to :
- solve all remaining bugs in the tracker
- remove the unused #errors_for method. Please give some input if you do !
- add some unit-tests.

This will result in a short-term release with not too much changes,
used for code stabilization.

When this is done, I will embark on 2.0 for bigger changes like
Markaby and AR removal.

Cheers,
  zimbatm

From manfred at gmail.com  Sun Sep 23 17:31:50 2007
From: manfred at gmail.com (Manfred Stienstra)
Date: Sun, 23 Sep 2007 23:31:50 +0200
Subject: Next camping release
In-Reply-To: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
Message-ID: <302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>

> This will result in a short-term release with not too much changes,
> used for code stabilization.
>
> When this is done, I will embark on 2.0 for bigger changes like
> Markaby and AR removal.

Cool, I'm currently trying to get my apps working with svn camping. I  
think I've found a problem surrounding URL(). Jonas, can you try to  
float around #camping to discuss any problems?

Manfred

From walkandre at gmail.com  Sun Sep 23 18:19:44 2007
From: walkandre at gmail.com (=?ISO-8859-1?Q?andr=E9_gustavo_cardozo?=)
Date: Sun, 23 Sep 2007 19:19:44 -0300
Subject: Next camping release
In-Reply-To: <302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
Message-ID: <8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>

it would be really cool do remove the apache scriptAlias directive so
camping would run everywhere

On 9/23/07, Manfred Stienstra <manfred at gmail.com> wrote:
>
> > This will result in a short-term release with not too much changes,
> > used for code stabilization.
> >
> > When this is done, I will embark on 2.0 for bigger changes like
> > Markaby and AR removal.
>
> Cool, I'm currently trying to get my apps working with svn camping. I
> think I've found a problem surrounding URL(). Jonas, can you try to
> float around #camping to discuss any problems?
>
> Manfred
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Andr? G. Cardozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070923/de64dcb4/attachment.html 

From zimbatm at oree.ch  Sun Sep 23 18:27:26 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Mon, 24 Sep 2007 00:27:26 +0200
Subject: Next camping release
In-Reply-To: <302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
Message-ID: <e3caf1460709231527o33cd25cfn7c4af3505cbe2535@mail.gmail.com>

2007/9/23, Manfred Stienstra <manfred at gmail.com>:
> > This will result in a short-term release with not too much changes,
> > used for code stabilization.
> >
> > When this is done, I will embark on 2.0 for bigger changes like
> > Markaby and AR removal.
>
> Cool, I'm currently trying to get my apps working with svn camping. I
> think I've found a problem surrounding URL(). Jonas, can you try to
> float around #camping to discuss any problems?

I am not really an IRC user but I will try to.

I'd really appreciate if every concerned person could follow the
changesets and raise objection on the list. It is easy to follow if
you use rss feeds :
http://code.whytheluckystiff.net/camping/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss

-- 
Cheers,
  zimbatm

From zimbatm at oree.ch  Sun Sep 23 18:27:54 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Mon, 24 Sep 2007 00:27:54 +0200
Subject: Next camping release
In-Reply-To: <8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
Message-ID: <e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>

2007/9/24, andr? gustavo cardozo <walkandre at gmail.com>:
> it would be really cool do remove the apache scriptAlias directive so
> camping would run everywhere

Sure, could you file a bug for this ?

-- 
Cheers,
  zimbatm

From archengule at gmail.com  Mon Sep 24 18:36:25 2007
From: archengule at gmail.com (Michael Maltese)
Date: Mon, 24 Sep 2007 15:36:25 -0700
Subject: Next camping release
In-Reply-To: <e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
Message-ID: <56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>

Remove Markaby? How will that work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070924/b0bb582a/attachment.html 

From boss at topfunky.com  Mon Sep 24 18:40:38 2007
From: boss at topfunky.com (Geoffrey Grosenbach)
Date: Mon, 24 Sep 2007 15:40:38 -0700
Subject: [ANN] Mosquito TDD Framework Updated
Message-ID: <15754f7e0709241540s605206c0p8dced224fb454002@mail.gmail.com>

Mosquito, the TDD framework for Camping has been updated (0.1.3).
We've tried to keep it backwards compatible, so your apps should
continue to work. But feel free to submit a bug report at RubyForge if
you have any problems.

Changes:
http://rubyforge.org/frs/shownotes.php?group_id=351&release_id=14845

Download:
http://rubyforge.org/projects/mosquito/

Docs:
http://mosquito.rubyforge.org/

Thanks to contributions by new team member Julian 'Julik' Tarkhanov!

-- 
Geoffrey Grosenbach
boss at topfunky.com
http://peepcode.com

From zimbatm at oree.ch  Mon Sep 24 21:27:33 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Tue, 25 Sep 2007 03:27:33 +0200
Subject: Next camping release
In-Reply-To: <56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
Message-ID: <e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>

2007/9/25, Michael Maltese <archengule at gmail.com>:
> Remove Markaby? How will that work?

Only as a direct dependency. It will probably kept as an extension.
Basically, you can return a string containing html from your
controller methods even if it's a bit rough.

-- 
Cheers,
  zimbatm

From archengule at gmail.com  Mon Sep 24 22:24:53 2007
From: archengule at gmail.com (Michael Maltese)
Date: Mon, 24 Sep 2007 19:24:53 -0700
Subject: Next camping release
In-Reply-To: <e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
Message-ID: <56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>

That makes sense.
An extension, do you mean like camping/session?

On 9/24/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:
>
> 2007/9/25, Michael Maltese <archengule at gmail.com>:
> > Remove Markaby? How will that work?
>
> Only as a direct dependency. It will probably kept as an extension.
> Basically, you can return a string containing html from your
> controller methods even if it's a bit rough.
>
> --
> Cheers,
>   zimbatm
> _______________________________________________
> 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/20070924/24d68aba/attachment.html 

From manfred at gmail.com  Tue Sep 25 02:03:23 2007
From: manfred at gmail.com (Manfred Stienstra)
Date: Tue, 25 Sep 2007 08:03:23 +0200
Subject: [ANN] Mosquito TDD Framework Updated
In-Reply-To: <15754f7e0709241540s605206c0p8dced224fb454002@mail.gmail.com>
References: <15754f7e0709241540s605206c0p8dced224fb454002@mail.gmail.com>
Message-ID: <A42460DB-5E8A-4632-856F-FF53BA5B5BCF@gmail.com>


On Sep 25, 2007, at 12:40 AM, Geoffrey Grosenbach wrote:
> Thanks to contributions by new team member Julian 'Julik' Tarkhanov!

I was just going to remark that some changelog items have a very  
distinct Julian style to them. Thanks for the great work guys.

Manfred


From zimbatm at oree.ch  Tue Sep 25 08:53:58 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Tue, 25 Sep 2007 14:53:58 +0200
Subject: Next camping release
In-Reply-To: <56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
	<56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
Message-ID: <e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>

2007/9/25, Michael Maltese <archengule at gmail.com>:
> That makes sense.
> An extension, do you mean like camping/session?

Yes, and the gem dependency would only be added to camping-omnibus.
But first, let's release Camping 1.6

-- 
Cheers,
  zimbatm

From julian.tarkhanov at gmail.com  Tue Sep 25 16:14:26 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Tue, 25 Sep 2007 22:14:26 +0200
Subject: Session cookies not passed on first redirect
Message-ID: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>

Hello Campers!

Is it just me or does Camping  init the session twice on a redirect?  
If I have an app and when the user visits it for the first time, a  
session is generated. Afterwards I redirect the user in a service  
(that basically does auth) and he gets bounced to the login page -  
but when I arrive at the login page my SID somehow has changed :-( so  
there is a stale session dangling in the store and and empty @state.
After the second request (even if I fail auth or load a page that  
does not require it beforehand) everything is fine and dandy.

Herre is the service in question - if I do it like this the session  
is regenerated when the user lands on the signon page And the page he  
is redirected from was his first one
in the session

def service(*a)
       begin
         return super(*a)
       rescue PleaseLogin
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self
       end
       self
end

And this version works in all cases:

def service(*a)
       begin
         return super(*a)
       rescue PleaseLogin
         @headers['Set-Cookie'] = 'camping_sid=%s; path=/' %  
@cookies.camping_sid
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self
       end
       self
end

Of course the service is included before Camping::Session so the  
session service should wrap.

Has someone observed this behavior? Why is it needed to manually set  
the session cookie? Is it that the same as the workaround that  
mod_perl and mod_python use (as in "error headers" versus "normal  
headers")?

-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070925/e2999321/attachment.html 

From ruby at schmidtwisser.de  Tue Sep 25 16:31:17 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Tue, 25 Sep 2007 22:31:17 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
Message-ID: <2a50c7540709251331q55590c76m3b59b4000155f83a@mail.gmail.com>

Although I'm not sure, but I guess, that the exception is the reason
for this effect.

I think, but I'm not entirely sure that, within camping/session the
code in the service method after its super is not called, when the
exeption is raised. This code is the one, that sets the cookie
information.

This is the code in camping/session.rb

    def service(*a)
        session = Camping::Models::Session.persist @cookies
        app = self.class.name.gsub(/^(\w+)::.+$/, '\1')
        @state = (session[app] ||= Camping::H[])
        hash_before = Marshal.dump(@state).hash
        s = super(*a)
        if session
            hash_after = Marshal.dump(@state).hash
            unless hash_before == hash_after
                session[app] = @state
                session.save
            end
        end
        s
    end

The exception is raised in the super(*a) line, this transfer the
control flow to your rescue line and it never comes back.

The only possibility would be to avoid exceptions to manipulate your
control flow.

Cheers,

Gregor	

On 9/25/07, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com> wrote:
>
> Hello Campers!
>
> Is it just me or does Camping  init the session twice on a redirect? If I
> have an app and when the user visits it for the first time, a session is
> generated. Afterwards I redirect the user in a service (that basically does
> auth) and he gets bounced to the login page - but when I arrive at the login
> page my SID somehow has changed :-( so there is a stale session dangling in
> the store and and empty @state.
> After the second request (even if I fail auth or load a page that does not
> require it beforehand) everything is fine and dandy.
>
> Herre is the service in question - if I do it like this the session is
> regenerated when the user lands on the signon page And the page he is
> redirected from was his first one
> in the session
>
> def service(*a)
>       begin
>         return super(*a)
>       rescue PleaseLogin
>         redirect R(Pasaporte::Controllers::Signon,
> @nickname)
>         return self
>       end
>       self
> end
>
> And this version works in all cases:
>
>
> def service(*a)
>       begin
>         return super(*a)
>       rescue PleaseLogin
>         @headers['Set-Cookie'] = 'camping_sid=%s; path=/' %
> @cookies.camping_sid
>         redirect R(Pasaporte::Controllers::Signon,
> @nickname)
>         return self
>       end
>       self
> end
>
> Of course the service is included before Camping::Session so the session
> service should wrap.
> Has someone observed this behavior? Why is it needed to manually set the
> session cookie? Is it that the same as the workaround that mod_perl and
> mod_python use (as in "error headers" versus "normal headers")?
>
> --
> Julian 'Julik' Tarkhanov
> please send all personal mail to me at julik.nl
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From zimbatm at oree.ch  Tue Sep 25 16:50:22 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Tue, 25 Sep 2007 22:50:22 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
Message-ID: <e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>

Hi Julian,

can you try the attached patch applied to camping-trunk ?

-- 
Cheers,
  zimbatm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: camping-session.diff
Type: text/x-diff
Size: 646 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070925/1d6177be/attachment.bin 

From julian.tarkhanov at gmail.com  Tue Sep 25 17:08:02 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Tue, 25 Sep 2007 23:08:02 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
Message-ID: <36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>

On Sep 25, 2007, at 10:50 PM, Jonas Pfenniger wrote:

> can you try the attached patch applied to camping-trunk ?
> <camping-session.diff>

Will try. Cannot find the SVN URL on the site - only the trac is  
showing.

As of exceptions - in this case I catch the exception myself and  
return from underneath it, so it shouldn't be a problem.
This service(*a) is the "super" to Camping::Session (because  
Camping::Session gets included after it).

I suspect there is something with the cookie setter rather than with  
the Session service itself. But you are right - let's twist that flow  
one more bit :-)

-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070925/63dcf22a/attachment.html 

From julian.tarkhanov at gmail.com  Tue Sep 25 17:08:49 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Tue, 25 Sep 2007 23:08:49 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <2a50c7540709251331q55590c76m3b59b4000155f83a@mail.gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<2a50c7540709251331q55590c76m3b59b4000155f83a@mail.gmail.com>
Message-ID: <F983F9E2-8AE6-49FD-90A1-BA5C37C6EC4A@gmail.com>


On Sep 25, 2007, at 10:31 PM, Gregor Schmidt wrote:
> The exception is raised in the super(*a) line, this transfer the
> control flow to your rescue line and it never comes back.

It does come back because

rescue PleaseLogin
         @headers['Set-Cookie'] = 'camping_sid=%s; path=/' %  
@cookies.camping_sid
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self <<< this is the comeback
       end
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070925/2747a66a/attachment.html 

From zimbatm at oree.ch  Tue Sep 25 17:20:49 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Tue, 25 Sep 2007 23:20:49 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
Message-ID: <e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>

2007/9/25, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com>:
> Cannot find the SVN URL on the site - only the trac is showing.

`svn co http://code.whytheluckystiff.net/svn/camping/trunk`

-- 
Cheers,
  zimbatm

From julian.tarkhanov at gmail.com  Tue Sep 25 17:57:25 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Tue, 25 Sep 2007 23:57:25 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
Message-ID: <0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>


On Sep 25, 2007, at 11:20 PM, Jonas Pfenniger wrote:

> 2007/9/25, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com>:
>> Cannot find the SVN URL on the site - only the trac is showing.
>
> `svn co http://code.whytheluckystiff.net/svn/camping/trunk`

Thx. Checked that. No the issue isn't fixed. I suspect something is  
wrong with the cookie code, not with the session code (setting the  
cookie manually works after all).


-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070925/ea54404e/attachment.html 

From julian.tarkhanov at gmail.com  Tue Sep 25 18:19:05 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 00:19:05 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
Message-ID: <113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>


On Sep 25, 2007, at 11:57 PM, Julian 'Julik' Tarkhanov wrote:
> Thx. Checked that. No the issue isn't fixed. I suspect something is  
> wrong with the cookie code, not with the session code (setting the  
> cookie manually works after all).

Ok, with the trunk Camping it gets even more interesting! I loose the  
session on _all_ redirects now.

Camping.goes :Findme
require 'camping/session'

module Findme
   include Camping::Session
   module Controllers
     class One < R('/stepone')
       def get
         @state = {"one" => 2}
         puts "1:" + @state.inspect
         redirect R(Two)
       end
     end

     class Two < R('/steptwo')
       def get
         @state.two = "This is in two"
         puts "2:" + @state.inspect
         redirect R(Three)
       end
     end

     class Three < R('/stepthree')
       def get
         @state.three = "This is in three"
         puts "3:" + @state.inspect
         return "Accumulated state across redirects: #{@state.inspect}"
         redirect R(Three)
       end
     end
   end
end

That's a bummer.
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/b2dcf37d/attachment.html 

From why at whytheluckystiff.net  Tue Sep 25 18:26:37 2007
From: why at whytheluckystiff.net (why the lucky stiff)
Date: Tue, 25 Sep 2007 17:26:37 -0500
Subject: putting away HashWithIndifferentAccess
Message-ID: <20070925222637.GG38176@beekeeper.hobix.com>

Hey, campineros.  And many good handshakes to zimbatm for getting
some patches applied.

So, yeah, I'd really like to get rid of any serious dependancies with
this 1.6 release.  Anything that's not in stdlib has to go.  Of course,
camping-omnibus will still assume the whole ActiveRecord, Markaby,
Mongrel setup that's in the history books.

Metaid can be removed and replaced with:

  def Object.meta_def n,&b
  (class<<self;self;end).instance_eval{define_method n,&b};end

Markaby's going to take much more work.  Part of the issue is: how
does an app tell Camping that it needs to use Markaby without
screwing up the other apps?  My hunch is we'll use some eval'd code
to override render per-App like you see in camping/db.rb.

The default will be plain strings:

  def render *a,&b;s=send(*a,&b);s=send(:layout){s} if /^_/!~a[0].
  to_s and m.respond_to?:layout;s;end

And, well, as for ActiveSupport, Camping only uses the supra-
flexi-careless-hash, so we need a replacement.

I'm not too hot on [symbol] and [string] equivalence.  But I do like
to call the query string vars like methods.  What do you think about
using OpenStruct instead?

I've been testing with this:

  class H < OpenStruct
    def u h;for k,v in h;@table[k.to_sym]=v;new_ostruct_member(k);end
    def self.[] *a;new *a;end
  en

Or, you know, just Hash is okay, right folks?

_why

From julian.tarkhanov at gmail.com  Tue Sep 25 18:35:58 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 00:35:58 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070925222637.GG38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
Message-ID: <0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>


On Sep 26, 2007, at 12:26 AM, why the lucky stiff wrote:

>  class H < OpenStruct

How about

class H < (HashWithIndifferentAccess rescue Hash)

for the lesser among us (who always include and require)?
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/b5f38c06/attachment-0001.html 

From evan at cloudbur.st  Tue Sep 25 18:45:07 2007
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 25 Sep 2007 18:45:07 -0400
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>
Message-ID: <b6f68fc60709251545n45eb6a3ep1597a0e7781ccf9f@mail.gmail.com>

Regular hashes are good. Would need to make a decision whether to
prefer string or symbol keys.

String is easier to support; Symbol looks prettier in your editor.

Evan

On 9/25/07, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com> wrote:
>
>
> On Sep 26, 2007, at 12:26 AM, why the lucky stiff wrote:
>
>
>  class H < OpenStruct
>
> How about
>
> class H < (HashWithIndifferentAccess rescue Hash)
>
> for the lesser among us (who always include and require)?
>
> --
> Julian 'Julik' Tarkhanov
> please send all personal mail to me at julik.nl
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>


-- 
Evan Weaver
Cloudburst, LLC

From julian.tarkhanov at gmail.com  Tue Sep 25 18:48:08 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 00:48:08 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <b6f68fc60709251545n45eb6a3ep1597a0e7781ccf9f@mail.gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>
	<b6f68fc60709251545n45eb6a3ep1597a0e7781ccf9f@mail.gmail.com>
Message-ID: <9F988521-E4C4-481F-9778-7EE33694719C@gmail.com>

On Sep 26, 2007, at 12:45 AM, Evan Weaver wrote:
> Symbol looks prettier in your editor.
How do you parametrize symbols into a QS or pass them from a browser?  
I'd say strings will do with an optional HWIA for the ones who do.
I do smoke ActiveSupport, at least because of all the unicody  
goodness we've put in there.
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/cc96887d/attachment.html 

From aredridel at nbtsc.org  Tue Sep 25 18:32:48 2007
From: aredridel at nbtsc.org (Aria Stewart)
Date: Tue, 25 Sep 2007 16:32:48 -0600
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070925222637.GG38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
Message-ID: <1190759568.9373.0.camel@eridani.theinternetco.net>


> I'm not too hot on [symbol] and [string] equivalence.  But I do like
> to call the query string vars like methods.  What do you think about
> using OpenStruct instead?
> 
> I've been testing with this:
> 
>   class H < OpenStruct
>     def u h;for k,v in h;@table[k.to_sym]=v;new_ostruct_member(k);end
>     def self.[] *a;new *a;end
>   en
> 

I'm a fan!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070925/6fb1bf83/attachment.bin 

From mental at rydia.net  Tue Sep 25 18:42:00 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 25 Sep 2007 15:42:00 -0700
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070925222637.GG38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
Message-ID: <54d5f8b35bb8d576ff4b4e803515d753@localhost>

On Tue, 25 Sep 2007 17:26:37 -0500, why the lucky stiff <why at whytheluckystiff.net> wrote:

> I'm not too hot on [symbol] and [string] equivalence.  But I do like
> to call the query string vars like methods.  What do you think about
> using OpenStruct instead?
> 
> I've been testing with this:
> 
>   class H < OpenStruct
>     def u h;for k,v in h;@table[k.to_sym]=v;new_ostruct_member(k);end
>     def self.[] *a;new *a;end
>   en
> 
> Or, you know, just Hash is okay, right folks?

I'd be fine with just Hash.  OpenStruct is cool and all, but if this
is to be used for query parameters you're going to have to be really
paranoid about key names (e.g. imagine a query with a variable named
new_ostruct_member).

-mental


From julian.tarkhanov at gmail.com  Tue Sep 25 19:30:34 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 01:30:34 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <54d5f8b35bb8d576ff4b4e803515d753@localhost>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<54d5f8b35bb8d576ff4b4e803515d753@localhost>
Message-ID: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>


On Sep 26, 2007, at 12:42 AM, MenTaLguY wrote:

> you're going to have to be really
> paranoid about key names (e.g. imagine a query with a variable named
> new_ostruct_member).

>> @table[k.to_sym]=v;new_ostruct_member(k)

this might already be a server crasher. you know how many unique  
to_syms you can do before the table is full?
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/3d5052ef/attachment.html 

From mental at rydia.net  Tue Sep 25 20:05:04 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 25 Sep 2007 17:05:04 -0700
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
References: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
Message-ID: <e564a1d0c73b8156536d69939ab36702@localhost>

On Wed, 26 Sep 2007 01:30:34 +0200, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com> wrote:
>> you're going to have to be really
>> paranoid about key names (e.g. imagine a query with a variable named
>> new_ostruct_member).
> 
>>> @table[k.to_sym]=v;new_ostruct_member(k)
> 
> this might already be a server crasher. you know how many unique
> to_syms you can do before the table is full?

Ah, yeah, good catch.  Actually any approach which let you access
query parameters as methods would have that problem -- behind the
scenes, every uniquely named method introduces a symbol.  This is
even a potential issue for approaches using method_missing, since
in MRI, rb_call wants an ID (normally obtained via rb_to_id).

-mental


From julian.tarkhanov at gmail.com  Tue Sep 25 20:05:51 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 02:05:51 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
Message-ID: <01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>

Well' I know this might sound very weird (it is!) - but it was  
theactiverecordeverybodyhates. I mean sometimes you shoudn't be  
greedy and just give them that ID.

If I do the following
-                create_table :sessions, :force => true, :id => false  
do |t|
+                create_table :sessions, :force => true do |t|

everything gets rollin', on trunk or otherwise.
Can't post an attachment to trac so here it is

?
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-sessions.diff
Type: application/octet-stream
Size: 1305 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment-0001.html 

From julian.tarkhanov at gmail.com  Tue Sep 25 20:16:31 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 02:16:31 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <e564a1d0c73b8156536d69939ab36702@localhost>
References: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
	<e564a1d0c73b8156536d69939ab36702@localhost>
Message-ID: <1252DDA1-7CE1-4A3C-A1F7-98AF0B02BF4C@gmail.com>


On Sep 26, 2007, at 2:05 AM, MenTaLguY wrote:

> behind the
> scenes, every uniquely named method introduces a symbol.
yep. but then it's _you_ who calls that accessor, not some John Doe  
who sends you a POST :-)

-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/5cd2ee4a/attachment.html 

From evan at cloudbur.st  Tue Sep 25 22:24:08 2007
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 25 Sep 2007 22:24:08 -0400
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<54d5f8b35bb8d576ff4b4e803515d753@localhost>
	<80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
Message-ID: <b6f68fc60709251924s69a2ec5dud3df8a099711a1c1@mail.gmail.com>

On 9/25/07, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com> wrote:
> this might already be a server crasher. you know how many unique to_syms you
> can do before the table is full?

As far as I can tell, sym_tbl is just a regular st_table, so it's an
expanding array similar to the Ruby heap. So there's no danger of hard
crash. If your camping process runs for a month you should end up with
no more than 10 or 20 extra mbs of memory used in anything but a
deliberately pathological situation.

Evan

-- 
Evan Weaver
Cloudburst, LLC

From why at whytheluckystiff.net  Wed Sep 26 00:10:17 2007
From: why at whytheluckystiff.net (why the lucky stiff)
Date: Tue, 25 Sep 2007 23:10:17 -0500
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <e564a1d0c73b8156536d69939ab36702@localhost>
References: <80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
	<e564a1d0c73b8156536d69939ab36702@localhost>
Message-ID: <20070926041016.GH38176@beekeeper.hobix.com>

On Tue, Sep 25, 2007 at 05:05:04PM -0700, MenTaLguY wrote:
> Ah, yeah, good catch.  Actually any approach which let you access
> query parameters as methods would have that problem -- behind the
> scenes, every uniquely named method introduces a symbol.  This is
> even a potential issue for approaches using method_missing, since
> in MRI, rb_call wants an ID (normally obtained via rb_to_id).

Right, okay.  Well the current approach uses method_missing.

I say we just go with Hash and then have a specific option for using
HashWithIndifferentAccess.  I like this alot better, because it
means you can just set the option and things work just like 1.5 and
backwards.

  Camping.goes :Tepee
  Tepee.include HashWithIndifferentAccess
  Tepee.include Markaby

Err... or something.

Let's use Strings for Hash keys, since HWIA uses Strings internally,
which is likely to be nicer for ActiveRecord and because of symbol 
memory concerns, lastly.

_why

From zimbatm at oree.ch  Wed Sep 26 04:52:15 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Wed, 26 Sep 2007 10:52:15 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
	<01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
Message-ID: <e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>

Thanks Julian,

the little app helped a lot. Check changeset [225].
http://code.whytheluckystiff.net/camping/changeset/225

-- 
Cheers,
  zimbatm

From zimbatm at oree.ch  Wed Sep 26 05:33:42 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Wed, 26 Sep 2007 11:33:42 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070925222637.GG38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
Message-ID: <e3caf1460709260233j47c3fc2ercb5d9e9d874b000d@mail.gmail.com>

2007/9/26, why the lucky stiff <why at whytheluckystiff.net>:
> Hey, campineros.  And many good handshakes to zimbatm for getting
> some patches applied.

You're welcome !

> Markaby's going to take much more work.  Part of the issue is: how
> does an app tell Camping that it needs to use Markaby without
> screwing up the other apps?  My hunch is we'll use some eval'd code
> to override render per-App like you see in camping/db.rb.

Adding method_missing to the views would be enough to proxy the calls
to Markaby. You'd still need to propagate the controller's instance
variables to the view tough.

One solution is to add the View into the controller. The disadvantages
is that it greaten the chances of method clashes and that the
distinction between Helper and Base module would be null. The
advantage is that method_missing could be reused, like it is for the
NotFound and ServerError classes.

> And, well, as for ActiveSupport, Camping only uses the supra-
> flexi-careless-hash, so we need a replacement.

I suggest that H is a child of Hash. Extensions can extend it to
provide method_missing goodness or anything else. The only concern I
have is about case-sensitiveness. I am not sure if the http headers
are normalized on input or not.

-- 
Cheers,
  zimbatm

From julian.tarkhanov at gmail.com  Wed Sep 26 08:31:46 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 14:31:46 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
	<01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
	<e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>
Message-ID: <5237E494-8BBA-4F89-AAED-4AD8C0F52B79@gmail.com>

On Sep 26, 2007, at 10:52 AM, Jonas Pfenniger wrote:
> the little app helped a lot. Check changeset [225].
> http://code.whytheluckystiff.net/camping/changeset/225

Coolio! You can optionally try my patch for session.rb because it  
makes them neater and does not do bypasses. But the idea with the  
hideuous
injection is in our spirit yess :-)
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/03d5ab15/attachment.html 

From zimbatm at oree.ch  Wed Sep 26 08:42:35 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Wed, 26 Sep 2007 14:42:35 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <5237E494-8BBA-4F89-AAED-4AD8C0F52B79@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
	<01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
	<e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>
	<5237E494-8BBA-4F89-AAED-4AD8C0F52B79@gmail.com>
Message-ID: <e3caf1460709260542p68365620k21fd37c82a9363ce@mail.gmail.com>

2007/9/26, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com>:
> Coolio! You can optionally try my patch for session.rb because it makes them
> neater and does not do bypasses.

I am not really confident with the eternally growing id. I guess it
depends on the database, but a 65535 items limit can be obtained
pretty fast depending on the conditions.

-- 
Cheers,
  zimbatm

From julian.tarkhanov at gmail.com  Wed Sep 26 08:46:59 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 14:46:59 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <e3caf1460709260542p68365620k21fd37c82a9363ce@mail.gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<e3caf1460709251350u173140bblf2e61c30db63c8e1@mail.gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
	<01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
	<e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>
	<5237E494-8BBA-4F89-AAED-4AD8C0F52B79@gmail.com>
	<e3caf1460709260542p68365620k21fd37c82a9363ce@mail.gmail.com>
Message-ID: <E7F94ADB-E102-4FF5-A6C4-36C43B310D37@gmail.com>


On Sep 26, 2007, at 2:42 PM, Jonas Pfenniger wrote:

> I am not really confident with the eternally growing id. I guess it
> depends on the database, but a 65535 items limit can be obtained
> pretty fast depending on the conditions.

True, didnt think about that in this sense. Well let's carry on then :-)
-1 for my netaness and I set out on the test corpus this weekend
this kind of stuff is something we _really_ should have known before
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/8b831ce6/attachment.html 

From julian.tarkhanov at gmail.com  Wed Sep 26 08:50:26 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 14:50:26 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <b6f68fc60709251924s69a2ec5dud3df8a099711a1c1@mail.gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<54d5f8b35bb8d576ff4b4e803515d753@localhost>
	<80BCE84D-05BC-4321-A64E-B42F354BDCDD@gmail.com>
	<b6f68fc60709251924s69a2ec5dud3df8a099711a1c1@mail.gmail.com>
Message-ID: <C11A68B3-8F60-46EF-BCF5-C875AFAD054C@gmail.com>


On Sep 26, 2007, at 4:24 AM, Evan Weaver wrote:

> As far as I can tell, sym_tbl is just a regular st_table, so it's an
> expanding array similar to the Ruby heap.

Oddly enough, this:

c = 0
loop { c += 1; puts "two_symbols_sitting_in_a_tree_#{c}".to_sym }
was a total crasher on 1.8.5 but works on 1.8.6 p110. Don't have time  
to build 1.8.5. again and check, unfortunately.

But as people say that symbol table is not even GCed I would avoid  
converting people's input into symbols anyway.

-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/84999230/attachment.html 

From zimbatm at oree.ch  Wed Sep 26 08:58:08 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Wed, 26 Sep 2007 14:58:08 +0200
Subject: Session cookies not passed on first redirect
In-Reply-To: <E7F94ADB-E102-4FF5-A6C4-36C43B310D37@gmail.com>
References: <6E72AB80-445F-4600-A3EE-79342EC3B816@gmail.com>
	<36F248EE-45EA-4BB7-98E3-5301B8B69C0D@gmail.com>
	<e3caf1460709251420q5904ff7fsf5a45e3d84e67669@mail.gmail.com>
	<0CA39460-4D65-426F-851D-7B2CB5924920@gmail.com>
	<113225D7-94B5-4ECF-AA05-389345FB4B02@gmail.com>
	<01604249-2CE6-4836-A08B-7F2EC717DB78@gmail.com>
	<e3caf1460709260152l389954e6w15ca5ecb414a2dc8@mail.gmail.com>
	<5237E494-8BBA-4F89-AAED-4AD8C0F52B79@gmail.com>
	<e3caf1460709260542p68365620k21fd37c82a9363ce@mail.gmail.com>
	<E7F94ADB-E102-4FF5-A6C4-36C43B310D37@gmail.com>
Message-ID: <e3caf1460709260558r30c63cbbsfdd2ba2104f66670@mail.gmail.com>

2007/9/26, Julian 'Julik' Tarkhanov <julian.tarkhanov at gmail.com>:
> pretty fast depending on the conditions.
> True, didnt think about that in this sense. Well let's carry on then :-)-1
> for my netaness and I set out on the test corpus this weekend
> this kind of stuff is something we _really_ should have known before

Well, I don't use sessions so I don't care :-p

-- 
Cheers,
  zimbatm

From julian.tarkhanov at gmail.com  Wed Sep 26 10:04:59 2007
From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov)
Date: Wed, 26 Sep 2007 16:04:59 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<0AA0EC06-C2E7-4FE2-82DA-5522848F1D5D@gmail.com>
Message-ID: <29912B95-319A-4DDE-9A53-7DBABF65B519@gmail.com>


On Sep 26, 2007, at 12:35 AM, Julian 'Julik' Tarkhanov wrote:
> class H < (HashWithIndifferentAccess rescue Hash)

To be clear, I'm really for the hash also because I use the "obj =  
@items.delete" paradigm to signify
"take this item out because we'll work with it"). But you can  
optionally shortcut nil assignment to delete (which would be nasty).
-- 
Julian 'Julik' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070926/cc49bb57/attachment-0001.html 

From zimbatm at oree.ch  Wed Sep 26 17:13:45 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Wed, 26 Sep 2007 23:13:45 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070925222637.GG38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
Message-ID: <e3caf1460709261413j7082676ft7746a7612e002412@mail.gmail.com>

Minimal HWIA removal patch attached. So far, the examples, file
upload, sessions, all work under mongrel with the patch applied.

_why, is it something like that that you want ?

I'm not even sure if HWIA extension is useful. The method_missing
shortcut is even shorter than the one with :symbols.

-- 
Cheers,
  zimbatm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: camping-no-HWIA.diff
Type: text/x-diff
Size: 2944 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070926/a05a4f0f/attachment.bin 

From ernest.prabhakar at gmail.com  Wed Sep 26 18:31:37 2007
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Wed, 26 Sep 2007 15:31:37 -0700
Subject: WEBrick Re: Next camping release
In-Reply-To: <e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
	<56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
	<e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>
Message-ID: <DDA8F534-2AA7-4DF9-AA51-184F82BBD174@gmail.com>

Hi all,

I was looking at the test cases on the changeset:

http://code.whytheluckystiff.net/camping/browser/trunk/test?rev=227

However, I didn't see anything about testing with different web  
browsers; which is a concern since there was a nasty WEBrick bug in  
the last version.  Is there test coverage for that?

-- Ernie P.

P.S. I mean to file the bug, but got into a fight with the trac  
system. ;-(

From why at whytheluckystiff.net  Wed Sep 26 18:57:20 2007
From: why at whytheluckystiff.net (why the lucky stiff)
Date: Wed, 26 Sep 2007 17:57:20 -0500
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <e3caf1460709260233j47c3fc2ercb5d9e9d874b000d@mail.gmail.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<e3caf1460709260233j47c3fc2ercb5d9e9d874b000d@mail.gmail.com>
Message-ID: <20070926225720.GI38176@beekeeper.hobix.com>

On Wed, Sep 26, 2007 at 11:33:42AM +0200, Jonas Pfenniger wrote:
> I suggest that H is a child of Hash. Extensions can extend it to
> provide method_missing goodness or anything else. The only concern I
> have is about case-sensitiveness. I am not sure if the http headers
> are normalized on input or not.

Well, case-sensitiveness would be a prob with 1.5 as well.  Since
@env.HTTP_HOST will work and @env.http_host will not.

_why

From zimbatm at oree.ch  Thu Sep 27 04:44:56 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Thu, 27 Sep 2007 10:44:56 +0200
Subject: WEBrick Re: Next camping release
In-Reply-To: <DDA8F534-2AA7-4DF9-AA51-184F82BBD174@gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
	<56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
	<e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>
	<DDA8F534-2AA7-4DF9-AA51-184F82BBD174@gmail.com>
Message-ID: <e3caf1460709270144y56c9f0b9lca951d9e3265896b@mail.gmail.com>

2007/9/27, Ernest Prabhakar <ernest.prabhakar at gmail.com>:
> I was looking at the test cases on the changeset:
>
> http://code.whytheluckystiff.net/camping/browser/trunk/test?rev=227
>
> However, I didn't see anything about testing with different web
> browsers; which is a concern since there was a nasty WEBrick bug in
> the last version.  Is there test coverage for that?

Hi Ernie,

I didn't get into testing the various web servers yet. Ref 277 is the
base to do that, since those apps can be tested against the various
web servers. I know there are some issues with FastCGI too so I'll
have to get into it anyways.

> P.S. I mean to file the bug, but got into a fight with the trac
> system. ;-(

You need a http://rubyforge.org/ account, which you can then reuse
here : http://code.whytheluckystiff.net/access/
Once you are registered, you can log into the various Trac
applications. File upload doesn't work tough.

Anyways, you can still describe your bug on the list and I'll see what to do.

-- 
Cheers,
  zimbatm

From manfred at gmail.com  Thu Sep 27 05:00:48 2007
From: manfred at gmail.com (Manfred Stienstra)
Date: Thu, 27 Sep 2007 11:00:48 +0200
Subject: WEBrick Re: Next camping release
In-Reply-To: <e3caf1460709270144y56c9f0b9lca951d9e3265896b@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
	<56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
	<e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>
	<DDA8F534-2AA7-4DF9-AA51-184F82BBD174@gmail.com>
	<e3caf1460709270144y56c9f0b9lca951d9e3265896b@mail.gmail.com>
Message-ID: <AF97F799-4FA3-485D-82F6-656054228148@gmail.com>


On Sep 27, 2007, at 10:44, Jonas Pfenniger wrote:

>> P.S. I mean to file the bug, but got into a fight with the trac
>> system. ;-(

Patch uploads seem to be broken, so maybe _why can have a look-see?

Manfred

From ruby at schmidtwisser.de  Thu Sep 27 07:25:48 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Thu, 27 Sep 2007 13:25:48 +0200
Subject: Camping and ruby2ruby
Message-ID: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>

Hi everybody,

I would like to use ruby2ruby in a caming project, but there seems to
be an incompatibility with camping, ruby2ruby and markaby.
Unfortunately I receive strange Markaby::InvalidXhtmlErrors.

To demonstrate, that only combination of all three components causes
the problem I added the following code. I relies on Markaby and
ruby2ruby only and works fine (a.k.a. as expected).

    require "rubygems"
    require "ruby2ruby"
    require "markaby"

    def example(&block)
      $mab.pre( block.to_ruby.gsub(/^proc \{\n(.*)\n\}$/m, '\1'))
    end

    Markaby::Builder.set(:indent, 2)
    $mab = Markaby::Builder.new
    $mab.xhtml_strict do
      div.literate_markaby! do
        example do
          1 + 1 == 2
        end
      end
    end
    puts $mab.to_s

When I wrap that up in a camping project, which looks the following, I
get an error, when using tag! with arguments.

The Code:

    require "rubygems"
    require "ruby2ruby"

    Camping.goes :Test

    module Test
      module Controllers
        class Index < R '/'
          def get
            div.literate_programming! do
              example { 1 + 1 == 2 }
            end
          end
        end
      end

      module Helpers
        def example(&block)
          pre( block.to_ruby.gsub(/^proc \{\n(.*)\n\}$/m, '\1'))
        end
      end
    end

It raises "Markaby::InvalidXhtmlError no attribute `href' on div
elements:" in the line "div.literate_programming! do" . If I change it
to "div do" it works okay. Also every other way of providing arguments
raises the error (div.class_name, div(:rel => "options"), ...).

I don't know where the :href attribute comes from and I don't know,
why it only appears within camping and not in markaby itself.

Any help would be appreciated. Thanks in advance.

Cheers,

Gregor

Note: I'm using the latest release of camping (1.5.180), markaby (0.5)
and ruby2ruby (1.1.7)

From zimbatm at oree.ch  Thu Sep 27 09:03:33 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Thu, 27 Sep 2007 15:03:33 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
Message-ID: <e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>

Hi Gregor,

I wasn't able to track the error on Camping side, but it comes from
r2r that defines nil.error_missing.

2007/9/27, Gregor Schmidt <ruby at schmidtwisser.de>:
>     require "rubygems"
>     require "ruby2ruby"

# It works in this case but probably breaks r2r on a larger scale.
class NilClass
  undef method_missing
end

>     Camping.goes :Test
>
>     module Test
>       module Controllers
>         class Index < R '/'
>           def get
>             div.literate_programming! do
>               example { 1 + 1 == 2 }
>             end
>           end
>         end
>       end
>
>       module Helpers
>         def example(&block)
>           pre( block.to_ruby.gsub(/^proc \{\n(.*)\n\}$/m, '\1'))
>         end
>       end
>     end

> I don't know where the :href attribute comes from and I don't know,
> why it only appears within camping and not in markaby itself.

Camping overrides [:href,:action,:src] to translate relative links to
absolute ones. See Mab at the end of camping-unabridged.

-- 
Cheers,
  zimbatm

From ruby at schmidtwisser.de  Thu Sep 27 10:22:19 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Thu, 27 Sep 2007 16:22:19 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
Message-ID: <2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>

On 9/27/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:
> Hi Gregor,
>
> I wasn't able to track the error on Camping side, but it comes from
> r2r that defines nil.error_missing.
>
> 2007/9/27, Gregor Schmidt <ruby at schmidtwisser.de>:
> >     require "rubygems"
> >     require "ruby2ruby"
>
> # It works in this case but probably breaks r2r on a larger scale.
> class NilClass
>   undef method_missing
> end
>
> >     Camping.goes :Test
> >
> >     module Test
> >       module Controllers
> >         class Index < R '/'
> >           def get
> >             div.literate_programming! do
> >               example { 1 + 1 == 2 }
> >             end
> >           end
> >         end
> >       end
> >
> >       module Helpers
> >         def example(&block)
> >           pre( block.to_ruby.gsub(/^proc \{\n(.*)\n\}$/m, '\1'))
> >         end
> >       end
> >     end
>
> > I don't know where the :href attribute comes from and I don't know,
> > why it only appears within camping and not in markaby itself.
>
> Camping overrides [:href,:action,:src] to translate relative links to
> absolute ones. See Mab at the end of camping-unabridged.
>

Thanks for the hint. Finally I manged to work around the incompatibility.

Defining NilClass#method_missing for nothing is not too clever, for a
large scale libary IMO.

By adding

    module Test  # This is my Camping app - not the test/unit test
thing (just a reminder)
      class Mab
        def tag!(*g,&b)
          super
        end
      end
    end

the problem is solved. Since I'm not changing any behaviour the code
should not have unwanted side effects. Perhaps this gives you an idea,
where the real cause of the problem is. At least I've got a solution
now.

Thanks for the help

Cheers,

Gregor

From zimbatm at oree.ch  Thu Sep 27 12:19:39 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Thu, 27 Sep 2007 18:19:39 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
Message-ID: <e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>

2007/9/27, Gregor Schmidt <ruby at schmidtwisser.de>:
> Defining NilClass#method_missing for nothing is not too clever, for a
> large scale libary IMO.

I'm not sure you understood, it is ruby2ruby who defined
nil.method_missing. We can't start to support each and every hack a
library will add to the Ruby core.

-- 
Cheers,
  zimbatm

From john.beppu at gmail.com  Thu Sep 27 13:35:43 2007
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 27 Sep 2007 10:35:43 -0700
Subject: Camping and ruby2ruby
In-Reply-To: <e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
Message-ID: <21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>

On 9/27/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:
>
> 2007/9/27, Gregor Schmidt <ruby at schmidtwisser.de>:
> > Defining NilClass#method_missing for nothing is not too clever, for a
> > large scale libary IMO.
>
> I'm not sure you understood, it is ruby2ruby who defined
> nil.method_missing. We can't start to support each and every hack a
> library will add to the Ruby core.



^for this reason, you can't really use ruby2ruby in anything serious.
nil.method_missing prevents a lot of exceptions from being thrown, and
there's a lot of code out their that legitimately needs those exceptions to
be thrown for correct behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070927/84e75ce5/attachment-0001.html 

From ernest.prabhakar at gmail.com  Thu Sep 27 13:54:43 2007
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Thu, 27 Sep 2007 10:54:43 -0700
Subject: WEBrick Re: Next camping release
In-Reply-To: <e3caf1460709270144y56c9f0b9lca951d9e3265896b@mail.gmail.com>
References: <e3caf1460709231258h7fd00b5bye0af5f0a69a7e5fe@mail.gmail.com>
	<302E843B-44F4-41E7-B6FA-D71E3610CD7F@gmail.com>
	<8e46cad20709231519j746c3154l6f8d8be534d8deae@mail.gmail.com>
	<e3caf1460709231527v410654f9r2fcb42f6790d8442@mail.gmail.com>
	<56f3a5570709241536y3adf5afp97d3879046303c3d@mail.gmail.com>
	<e3caf1460709241827l5d6aadf1rc405a035899ca7e5@mail.gmail.com>
	<56f3a5570709241924ue0fd54cxb8ab5eb58097b07e@mail.gmail.com>
	<e3caf1460709250553k4f0ff4bfv7295d48f0c62896c@mail.gmail.com>
	<DDA8F534-2AA7-4DF9-AA51-184F82BBD174@gmail.com>
	<e3caf1460709270144y56c9f0b9lca951d9e3265896b@mail.gmail.com>
Message-ID: <B13ACF21-7309-4F5E-9A28-6A54A0BA1F02@gmail.com>

Hi Jonas,

On Sep 27, 2007, at 1:44 AM, Jonas Pfenniger wrote:
> I didn't get into testing the various web servers yet. Ref 277 is the
> base to do that, since those apps can be tested against the various
> web servers. I know there are some issues with FastCGI too so I'll
> have to get into it anyways.

Thanks.  The problem was a typo in webrick.rb, but it looks like it  
is fixed in trunk, so I won't worry about it.

If I run into other issues, I'll be sure to fix them.

Best,
-- Ernie P.

>


From manfred at gmail.com  Thu Sep 27 14:08:11 2007
From: manfred at gmail.com (Manfred Stienstra)
Date: Thu, 27 Sep 2007 20:08:11 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
Message-ID: <E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>

On Sep 27, 2007, at 7:35 PM, John Beppu wrote:
> ^for this reason, you can't really use ruby2ruby in anything  
> serious.  nil.method_missing prevents a lot of exceptions from  
> being thrown, and there's a lot of code out their that legitimately  
> needs those exceptions to be thrown for correct behavior.

require 'ruby2ruby'
class NilClass
   undef method_missing
end

Solved?


From mcs532 at drexel.edu  Thu Sep 27 15:26:01 2007
From: mcs532 at drexel.edu (Matthew Snyder)
Date: Thu, 27 Sep 2007 15:26:01 -0400
Subject: FastCGI in Shared Hosting - What To Do?
Message-ID: <48fc445632.4563248fc4@drexel.edu>

Hello Campers!

I am working on Site5, trying to get a working Camping application
running. Unfortunately, my sole option in terms of deployment is FastCGI.
I have no access to sudo so I cannot create ScriptAliases.

I've taken the Camping Short Short Example and uploaded it, along with a
dispatch.fcgi and an .htaccess file.

My question is - given the state of Camping development right now, what
should each of these look like? I've tried multiple solutions offered on
the mailing lists, from Post-ambles to Campingrcs, and no combination
seems to work.

What I have so far:
* The original Short Short Camping example, with the class HomePage
changed to  Beta.
* This .htaccess:
 AddHandler fastcgi-script .fcgi
 Options +FollowSymLinks +ExecCGI

 RewriteEngine On
 RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
 RewriteCond %{REQUEST_URI} ^/failed_auth.html$ [OR]
 #RewriteCond %{REQUEST_URI} ^/static/(.*)$ [OR]
 RewriteCond %{REQUEST_URI} ^/mint/(.*)$
 RewriteRule ^.*$ - [L]

 RewriteRule ^$ index.html [QSA]
 RewriteRule ^([^.]+)$ $1.html [QSA]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
* This dispatch.fcgi:
 #!/usr/bin/ruby
 require 'rubygems'
 require 'camping/fastcgi'
 Camping::FastCGI.start('~/www/beta/beta.rb')

Thanks for all your help in advance!


From john.beppu at gmail.com  Thu Sep 27 15:44:03 2007
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 27 Sep 2007 12:44:03 -0700
Subject: Camping and ruby2ruby
In-Reply-To: <E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
Message-ID: <21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>

On 9/27/07, Manfred Stienstra <manfred at gmail.com> wrote:
>
> On Sep 27, 2007, at 7:35 PM, John Beppu wrote:
> > ^for this reason, you can't really use ruby2ruby in anything
> > serious.  nil.method_missing prevents a lot of exceptions from
> > being thrown, and there's a lot of code out their that legitimately
> > needs those exceptions to be thrown for correct behavior.
>
> require 'ruby2ruby'
> class NilClass
>    undef method_missing
> end
>
> Solved?



I don't know.  What if ruby2ruby relied on the other behaviour?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070927/5dc72d95/attachment.html 

From ruby at schmidtwisser.de  Thu Sep 27 19:11:10 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Fri, 28 Sep 2007 01:11:10 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
Message-ID: <2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>

Sorry, if I was misunderstood with saying

> Defining NilClass#method_missing for nothing is not too clever, for a
> large scale libary IMO.

I was "insulting" ruby2ruby and not camping. So everthing is okay on this side.

I solved my particular problem with the combination of caming and
ruby2ruby and will not use it for something serious - just academics.

I was looking for help, concerning this issue, found it, thankfully,
on this list and will post a blog entry tomorrow, so other probably
will find it as well.

>From my side, everything is okay at this point. Thanks again for the
hint. There is nothing I could see, that should be changed inside of
caming to allow such a "strange" of standard behaviour.

Cheers,

Gregor

From zimbatm at oree.ch  Thu Sep 27 19:19:36 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 01:19:36 +0200
Subject: FastCGI in Shared Hosting - What To Do?
In-Reply-To: <48fc445632.4563248fc4@drexel.edu>
References: <48fc445632.4563248fc4@drexel.edu>
Message-ID: <e3caf1460709271619o3fab2e15pb63c6fe3e0517d49@mail.gmail.com>

Hi Matthew,

your setup looks fine but FastCGI is vicious, so don't abandon yet ! I
loathe fastcgi but I hope that this e-mail will help you a little bit.

Your ruby script looks fine but if you have an SSH access, you could
try to run it by hand. The expected result, is no output at all. If it
does, report back here. Terminate the app with Ctrl-C.

The second thing is that we must make sure that apache is configured
properly. You can find some inspiration here :
http://wiki.rubyonrails.org/rails/pages/HowtoSetupApacheWithFastCGIAndRubyBindings
>From the same page, it is said that it is better to use mod_fcgid
instead of mod_fastcgi because it is outdated. It would also probably
help if you could provide some apache error logs.

Finally, the rewrite engine is vicious too, in it's own way. So it's
probably better to deactivate it until the rest is working.

-- 
Cheers,
  zimbatm

From zimbatm at oree.ch  Thu Sep 27 19:25:12 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 01:25:12 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
	<2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
Message-ID: <e3caf1460709271625s2f28463bvc39bf62ed319c02b@mail.gmail.com>

2007/9/28, Gregor Schmidt <ruby at schmidtwisser.de>:
> I was "insulting" ruby2ruby and not camping. So everthing is okay on this side.

No problem. You can insult Camping if you want, if at least I get
understood. Joking aside, it's true that ruby2ruby still lacks some
maturity but it is an interesting project nonetheless. I have big
hopes that one day is will be usable to "platterize" camping.rb

-- 
Cheers,
  zimbatm

From ruby at schmidtwisser.de  Thu Sep 27 19:33:27 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Fri, 28 Sep 2007 01:33:27 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709271632n73c1a536wed32fbbf0b7b9c4b@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
	<2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
	<e3caf1460709271625s2f28463bvc39bf62ed319c02b@mail.gmail.com>
	<2a50c7540709271632n73c1a536wed32fbbf0b7b9c4b@mail.gmail.com>
Message-ID: <2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>

On 9/28/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:
> 2007/9/28, Gregor Schmidt <ruby at schmidtwisser.de>:
> > I was "insulting" ruby2ruby and not camping. So everthing is okay on this side.
>
> No problem. You can insult Camping if you want, if at least I get
> understood. Joking aside, it's true that ruby2ruby still lacks some
> maturity but it is an interesting project nonetheless. I have big
> hopes that one day is will be usable to "platterize" camping.rb

For a none native speaker. Could you give a synonym for "platterize".

Cheers,

Gregor

From mcs532 at drexel.edu  Thu Sep 27 22:38:25 2007
From: mcs532 at drexel.edu (Matthew Snyder)
Date: Thu, 27 Sep 2007 22:38:25 -0400
Subject: FastCGI in Shared Hosting - What To Do?
In-Reply-To: <e3caf1460709271619o3fab2e15pb63c6fe3e0517d49@mail.gmail.com>
References: <48fc445632.4563248fc4@drexel.edu>
	<e3caf1460709271619o3fab2e15pb63c6fe3e0517d49@mail.gmail.com>
Message-ID: <3D27D00D-6F31-4801-8C7B-9598E858C006@drexel.edu>

Running 'ruby beta.rb' produces no output and goes straight back to a  
prompt. Running 'ruby dispatch.fcgi' produces no output, and when I  
hit enter, I'm returned to a prompt.
This is the only thing I get in my error logs:
[Thu Sep 27 21:35:48 2007] [warn] FastCGI: (dynamic) server "/home/ 
ardekant/public_html/beta/dispatch.fcgi" has failed to remain running  
for 30 seconds given 3 attempts, its restart interval has been backed  
off to 600 seconds

I can't switch what Apache is using in terms of modules. I can add  
handlers for file extensions, and that's it.

By not using the rewrite engine, do you mean just remove my .htaccess  
while I test? What would I put in as a web address if that were the  
case? Right now http://beta.ardekantur.com points to that beta/  
directory where the Camping app, .htaccess, and dispatch are.

Thanks for your help!

On Sep 27, 2007, at 7:19 PM, Jonas Pfenniger wrote:

> Hi Matthew,
>
> your setup looks fine but FastCGI is vicious, so don't abandon yet ! I
> loathe fastcgi but I hope that this e-mail will help you a little bit.
>
> Your ruby script looks fine but if you have an SSH access, you could
> try to run it by hand. The expected result, is no output at all. If it
> does, report back here. Terminate the app with Ctrl-C.
>
> The second thing is that we must make sure that apache is configured
> properly. You can find some inspiration here :
> http://wiki.rubyonrails.org/rails/pages/ 
> HowtoSetupApacheWithFastCGIAndRubyBindings
>> From the same page, it is said that it is better to use mod_fcgid
> instead of mod_fastcgi because it is outdated. It would also probably
> help if you could provide some apache error logs.
>
> Finally, the rewrite engine is vicious too, in it's own way. So it's
> probably better to deactivate it until the rest is working.
>
> -- 
> Cheers,
>   zimbatm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From manfred at gmail.com  Fri Sep 28 01:32:36 2007
From: manfred at gmail.com (Manfred Stienstra)
Date: Fri, 28 Sep 2007 07:32:36 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270603l2ce51aeeh81beb703bd6c8faf@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
	<2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
	<e3caf1460709271625s2f28463bvc39bf62ed319c02b@mail.gmail.com>
	<2a50c7540709271632n73c1a536wed32fbbf0b7b9c4b@mail.gmail.com>
	<2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>
Message-ID: <01879924-721D-4981-BD31-ADBA65D387FD@gmail.com>


On Sep 28, 2007, at 1:33 AM, Gregor Schmidt wrote:

> For a none native speaker. Could you give a synonym for "platterize".

Trayerize, like 'handing someone something on a platter'.

From zimbatm at oree.ch  Fri Sep 28 04:43:56 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 10:43:56 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<2a50c7540709270722r60d7b886t36177953d8c05fb4@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
	<2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
	<e3caf1460709271625s2f28463bvc39bf62ed319c02b@mail.gmail.com>
	<2a50c7540709271632n73c1a536wed32fbbf0b7b9c4b@mail.gmail.com>
	<2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>
Message-ID: <e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>

2007/9/28, Gregor Schmidt <ruby at schmidtwisser.de>:
> For a none native speaker. Could you give a synonym for "platterize".

Sorry, from a non native speaker too. The term was probably badly chosen.

I was referring to the action that consist of taking
camping-unabridged.rb and create a "platter?" out of it. It is a
reference to the visual output that camping.rb gives.

-- 
Cheers,
  zimbatm

From ruby at schmidtwisser.de  Fri Sep 28 04:49:38 2007
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Fri, 28 Sep 2007 10:49:38 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>
References: <2a50c7540709270425i7f4928f3tb35c2b9aec1a470c@mail.gmail.com>
	<e3caf1460709270919p7386c069v299d0a680e38d7f9@mail.gmail.com>
	<21a10fe00709271035k7ce23db6i425c471da6a55d72@mail.gmail.com>
	<E04BAC74-FB56-4E68-B1E7-D7E5822D4DA1@gmail.com>
	<21a10fe00709271244s15c07dccm6d01d5bf79d0b19e@mail.gmail.com>
	<2a50c7540709271611v34cddfc3vdeeef390780de49@mail.gmail.com>
	<e3caf1460709271625s2f28463bvc39bf62ed319c02b@mail.gmail.com>
	<2a50c7540709271632n73c1a536wed32fbbf0b7b9c4b@mail.gmail.com>
	<2a50c7540709271633i20a11ae0mcb4ccf8e52a3dd2@mail.gmail.com>
	<e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>
Message-ID: <2a50c7540709280149k7aae7cecvc24d26034b4f6c1c@mail.gmail.com>

> I was referring to the action that consist of taking
> camping-unabridged.rb and create a "platter?" out of it. It is a
> reference to the visual output that camping.rb gives.

Ok, now I got it. That would be cool indeed.

Cheers,

Gregor

From zimbatm at oree.ch  Fri Sep 28 04:50:17 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 10:50:17 +0200
Subject: FastCGI in Shared Hosting - What To Do?
In-Reply-To: <3D27D00D-6F31-4801-8C7B-9598E858C006@drexel.edu>
References: <48fc445632.4563248fc4@drexel.edu>
	<e3caf1460709271619o3fab2e15pb63c6fe3e0517d49@mail.gmail.com>
	<3D27D00D-6F31-4801-8C7B-9598E858C006@drexel.edu>
Message-ID: <e3caf1460709280150x7200d741rab394bca906409ad@mail.gmail.com>

2007/9/28, Matthew Snyder <mcs532 at drexel.edu>:
> Running 'ruby beta.rb' produces no output and goes straight back to a
> prompt. Running 'ruby dispatch.fcgi' produces no output, and when I
> hit enter, I'm returned to a prompt.
> This is the only thing I get in my error logs:
> [Thu Sep 27 21:35:48 2007] [warn] FastCGI: (dynamic) server "/home/
> ardekant/public_html/beta/dispatch.fcgi" has failed to remain running
> for 30 seconds given 3 attempts, its restart interval has been backed
> off to 600 seconds

Hmm.. try something like this to get more output :

#!/usr/bin/ruby
begin
  require 'rubygems'
  require 'camping/fastcgi'
  Camping::FastCGI.start('~/www/beta/beta.rb')
rescue Object => ex
  File.open('err.log','w'){|f| f.write(ex.inspect);
f.write(ex.backtrace.join("\n")}
end

> By not using the rewrite engine, do you mean just remove my .htaccess
> while I test? What would I put in as a web address if that were the
> case? Right now http://beta.ardekantur.com points to that beta/
> directory where the Camping app, .htaccess, and dispatch are.

Yes, if I am right you can access it trough
http://beta.ardekantur.com/dispatch.fcgi

-- 
Cheers,
  zimbatm

From mental at rydia.net  Fri Sep 28 13:26:05 2007
From: mental at rydia.net (MenTaLguY)
Date: Fri, 28 Sep 2007 10:26:05 -0700
Subject: Camping and ruby2ruby
In-Reply-To: <e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>
References: <e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>
Message-ID: <99cf56361ed2526bea77df3fe5ace9b6@localhost>

On Fri, 28 Sep 2007 10:43:56 +0200, "Jonas Pfenniger" <zimbatm at oree.ch> wrote:
> I was referring to the action that consist of taking
> camping-unabridged.rb and create a "platter?" out of it. It is a
> reference to the visual output that camping.rb gives.

Perhaps "condensing" ?

-mental


From zimbatm at oree.ch  Fri Sep 28 14:58:07 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 20:58:07 +0200
Subject: Camping and ruby2ruby
In-Reply-To: <99cf56361ed2526bea77df3fe5ace9b6@localhost>
References: <e3caf1460709280143n60316a25l74dc2d66489bc172@mail.gmail.com>
	<99cf56361ed2526bea77df3fe5ace9b6@localhost>
Message-ID: <e3caf1460709281158s11a3a8cam8189a717417b8575@mail.gmail.com>

2007/9/28, MenTaLguY <mental at rydia.net>:
> Perhaps "condensing" ?

Yes, with a little touch of artistic sense added :)

Cheers,
  zimbatm

From nathaniel at talbott.ws  Fri Sep 28 15:22:23 2007
From: nathaniel at talbott.ws (Nathaniel Talbott)
Date: Fri, 28 Sep 2007 15:22:23 -0400
Subject: PUT (and friends) bug?
Message-ID: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>

As far as I can tell, sending an actual HTTP PUT request to a Camping
app will never parse the params out of the request body - or am I
going nuts? This code seems to say only POST's will parse the request
body:

  elsif @method == "post" and \
      e.CONTENT_TYPE == "application/x-www-form-urlencoded"
    q.u(C.qsp(@in.read))
  end

I looked for an easy spot to stick a test case, but didn't come up
with one... can anyone else confirm that this is an issue?


-- 
Nathaniel Talbott
<:((><

From rcoder at gmail.com  Fri Sep 28 15:26:56 2007
From: rcoder at gmail.com (Lennon Day-Reynolds)
Date: Fri, 28 Sep 2007 12:26:56 -0700
Subject: PUT (and friends) bug?
In-Reply-To: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
Message-ID: <5d4c61240709281226k6cba7d5cqbfe5291722be89d5@mail.gmail.com>

On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:
> As far as I can tell, sending an actual HTTP PUT request to a Camping
> app will never parse the params out of the request body - or am I
> going nuts? This code seems to say only POST's will parse the request
> body:
>
>   elsif @method == "post" and \
>       e.CONTENT_TYPE == "application/x-www-form-urlencoded"
>     q.u(C.qsp(@in.read))
>   end

I honestly wouldn't expect PUT (or any other HTTP actions other than
GET, POST, and HEAD) to pass the input through a normal form-decoding
step -- most of the time, the "payload" for a PUT is going to be XML,
JSON, or even raw binary.

Since browsers won't do PUT, why build in support for what amounts to
a browser-only MIME type (application/x-www-form-urlencoded)?

-Lennon

From nathaniel at talbott.ws  Fri Sep 28 15:37:48 2007
From: nathaniel at talbott.ws (Nathaniel Talbott)
Date: Fri, 28 Sep 2007 15:37:48 -0400
Subject: PUT (and friends) bug?
In-Reply-To: <5d4c61240709281226k6cba7d5cqbfe5291722be89d5@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<5d4c61240709281226k6cba7d5cqbfe5291722be89d5@mail.gmail.com>
Message-ID: <4ce336a20709281237u505e850en46e2f3ac75697084@mail.gmail.com>

On 9/28/07, Lennon Day-Reynolds <rcoder at gmail.com> wrote:

> I honestly wouldn't expect PUT (or any other HTTP actions other than
> GET, POST, and HEAD) to pass the input through a normal
> form-decoding step -- most of the time, the "payload" for a PUT is
> going to be XML, JSON, or even raw binary.
>
> Since browsers won't do PUT, why build in support for what amounts
> to a browser-only MIME type (application/x-www-form-urlencoded)?

It seems to me that most restful frameworks are assuming that you can
PUT the same as you can POST, i.e. that other than the verb (and what
you might do with it) the two will be treated the same.

I actually ran in to this problem while mussing around with my little
Camping testing framework, since I was assuming that doing a proper
PUT would have the same affect as doing a simulated PUT using a
special query parameter. But I was surprised to find out that I was
wrong, and that things aren't parsed as one would expect.

Of course, there's also the fact that while browsers don't *currently*
support form verbs besides POST, I'm hopeful that that may change
eventually.

So am I wrong in assuming that PUT and other non-GET verbs should
support application/x-www-form-urlencoded, or is this something that
should be made to behave more consistently?


-- 
Nathaniel Talbott
<:((><

From tlockney at gmail.com  Fri Sep 28 15:45:12 2007
From: tlockney at gmail.com (Thomas Lockney)
Date: Fri, 28 Sep 2007 12:45:12 -0700
Subject: PUT (and friends) bug?
In-Reply-To: <4ce336a20709281237u505e850en46e2f3ac75697084@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<5d4c61240709281226k6cba7d5cqbfe5291722be89d5@mail.gmail.com>
	<4ce336a20709281237u505e850en46e2f3ac75697084@mail.gmail.com>
Message-ID: <ae42e3d40709281245g24d6cc7w5a53f8f79c85b85d@mail.gmail.com>

On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:
> Of course, there's also the fact that while browsers don't *currently*
> support form verbs besides POST, I'm hopeful that that may change
> eventually.

Even if browsers do start supporting PUT requests, I'd be somewhat
shocked if they do use that MIME type since POST already handles that
case.

I'm curious what the specs say about the payload types for PUT... it's
been way too long since I read them.

~thomas

From rcoder at gmail.com  Fri Sep 28 15:45:38 2007
From: rcoder at gmail.com (Lennon Day-Reynolds)
Date: Fri, 28 Sep 2007 12:45:38 -0700
Subject: PUT (and friends) bug?
In-Reply-To: <4ce336a20709281237u505e850en46e2f3ac75697084@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<5d4c61240709281226k6cba7d5cqbfe5291722be89d5@mail.gmail.com>
	<4ce336a20709281237u505e850en46e2f3ac75697084@mail.gmail.com>
Message-ID: <5d4c61240709281245s286d657eub4f1584dae248628@mail.gmail.com>

On 9/28/07, Nathaniel Talbott <nathaniel at talbott.ws> wrote:
> It seems to me that most restful frameworks are assuming that you can
> PUT the same as you can POST, i.e. that other than the verb (and what
> you might do with it) the two will be treated the same.

This is a horrible Rails-ism, in my opinion. PUT and POST are entirely
different actions, and the weirdness that Rails uses to make one
masquerade as the other is hardly a "convention."

> I actually ran in to this problem while mussing around with my little
> Camping testing framework, since I was assuming that doing a proper
> PUT would have the same affect as doing a simulated PUT using a
> special query parameter. But I was surprised to find out that I was
> wrong, and that things aren't parsed as one would expect.
>
> Of course, there's also the fact that while browsers don't *currently*
> support form verbs besides POST, I'm hopeful that that may change
> eventually.

Sure, but in that case, they will likely be using PUT for direct file
uploads (i.e., in place of 'type="file"' inputs) not for structured
form submission, unless some data-binding framework like XForms has
been used to associate the form with a persistent data format.

> So am I wrong in assuming that PUT and other non-GET verbs should
> support application/x-www-form-urlencoded, or is this something that
> should be made to behave more consistently?

I don't know that there's any major disadvantage to having Camping
attempt to parse the request body if a) the request was made using a
non-GET verb and b) the MIME type for the request was set to
'application/x-www-form-urlencoded'. (Of course, it should fail
gracefully if this parsing fails, as a poorly-implemented HTTP client
might, for example, mis-match the MIME type and payload serialization
format.)

From zimbatm at oree.ch  Fri Sep 28 16:50:31 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Fri, 28 Sep 2007 22:50:31 +0200
Subject: PUT (and friends) bug?
In-Reply-To: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
Message-ID: <e3caf1460709281350m5e680cd9pb69cf084f6504f09@mail.gmail.com>

2007/9/28, Nathaniel Talbott <nathaniel at talbott.ws>:
> As far as I can tell, sending an actual HTTP PUT request to a Camping
> app will never parse the params out of the request body - or am I
> going nuts?

No you aren't at all. Actually, Camping is only a toy to quickly hack
small apps together. I am highly skeptical that we'll never be able to
implement the 397K of the HTTP1.1 rfc into it's 4K limitation but I
would be happy if somebody does it :) In the mean time, it doesn't
mean that it can't provide some facilities for extension. Actually,
the initialize method is the biggest method in Camping and I remember
_why talking about splitting it up.

Concerning the PUT method, the rfc starts it's description with the
following terms : "The PUT method requests that the enclosed entity be
stored under the supplied Request-URI." (sec9.6). As I understand it,
it is intended to store files under a specific URL, but who knows what
an "entity" exactly is ? If I am right, a form is not really a file
since it's entries order are not strictly defined. At least, it
rapidly becomes complex because the RFC doesn't specifies a strict
list of accepted verbs. From the standard ones, OPTION, GET, HEAD and
TRACE should be "safe" and thus not accepting "post" data I guess and
DELETE makes no sense with an entity attached but I didn't find any
MUST or SHOULD attached to that assertion.

-- 
Cheers,
  zimbatm

From aredridel at nbtsc.org  Fri Sep 28 16:55:48 2007
From: aredridel at nbtsc.org (Aria Stewart)
Date: Fri, 28 Sep 2007 14:55:48 -0600
Subject: PUT (and friends) bug?
In-Reply-To: <e3caf1460709281350m5e680cd9pb69cf084f6504f09@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<e3caf1460709281350m5e680cd9pb69cf084f6504f09@mail.gmail.com>
Message-ID: <1191012948.14231.2.camel@localhost>

On Fri, 2007-09-28 at 22:50 +0200, Jonas Pfenniger wrote:
> 2007/9/28, Nathaniel Talbott <nathaniel at talbott.ws>:
> > As far as I can tell, sending an actual HTTP PUT request to a Camping
> > app will never parse the params out of the request body - or am I
> > going nuts?
> 
> No you aren't at all. Actually, Camping is only a toy to quickly hack
> small apps together. I am highly skeptical that we'll never be able to
> implement the 397K of the HTTP1.1 rfc into it's 4K limitation but I
> would be happy if somebody does it :) In the mean time, it doesn't
> mean that it can't provide some facilities for extension. Actually,
> the initialize method is the biggest method in Camping and I remember
> _why talking about splitting it up.
> 
> Concerning the PUT method, the rfc starts it's description with the
> following terms : "The PUT method requests that the enclosed entity be
> stored under the supplied Request-URI." (sec9.6). As I understand it,
> it is intended to store files under a specific URL, but who knows what
> an "entity" exactly is ? If I am right, a form is not really a file
> since it's entries order are not strictly defined. At least, it
> rapidly becomes complex because the RFC doesn't specifies a strict
> list of accepted verbs. From the standard ones, OPTION, GET, HEAD and
> TRACE should be "safe" and thus not accepting "post" data I guess and
> DELETE makes no sense with an entity attached but I didn't find any
> MUST or SHOULD attached to that assertion.
> 

The entity is the requst body. It's in the RFC.

PUT does specify to store something -- there's response codes for "We
assigned a URI" (201 -- Created, with Location:)

It's very different than POST -- Far more semantic load than POST.

I'm using PUT in Camping with no trouble -- XML body, doing CalDAV --
and it works well. But it's totally different than POST, true.

Aria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070928/e577f8cf/attachment-0001.bin 

From zimbatm at oree.ch  Fri Sep 28 19:16:18 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Sat, 29 Sep 2007 01:16:18 +0200
Subject: putting away HashWithIndifferentAccess
In-Reply-To: <20070926225720.GI38176@beekeeper.hobix.com>
References: <20070925222637.GG38176@beekeeper.hobix.com>
	<e3caf1460709260233j47c3fc2ercb5d9e9d874b000d@mail.gmail.com>
	<20070926225720.GI38176@beekeeper.hobix.com>
Message-ID: <e3caf1460709281616n464cdfaei61e67ce220ad167b@mail.gmail.com>

2007/9/27, why the lucky stiff <why at whytheluckystiff.net>:
> Well, case-sensitiveness would be a prob with 1.5 as well.  Since
> @env.HTTP_HOST will work and @env.http_host will not.

True. So what do you think of the attached patch ? It removes roughly
50 octets to camping.rb and seems to work pretty well, except for apps
that used :symbols to access H members.

-- 
Cheers,
  zimbatm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: camping-no-HWIA.diff
Type: text/x-diff
Size: 4911 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070929/baa051db/attachment.bin 

From whateley at gmail.com  Fri Sep 28 21:23:57 2007
From: whateley at gmail.com (Brendan Taylor)
Date: Fri, 28 Sep 2007 19:23:57 -0600
Subject: PUT (and friends) bug?
In-Reply-To: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
Message-ID: <20070929012357.GB29057@nyarlathotep>

On Fri, Sep 28, 2007 at 03:22:23PM -0400, Nathaniel Talbott wrote:
> As far as I can tell, sending an actual HTTP PUT request to a Camping
> app will never parse the params out of the request body - or am I
> going nuts? This code seems to say only POST's will parse the request
> body:
> 
>   elsif @method == "post" and \
>       e.CONTENT_TYPE == "application/x-www-form-urlencoded"
>     q.u(C.qsp(@in.read))
>   end

The @method == "post" test is a vestige of when Camping just parsed
anything that was POSTed. I didn't really think about it when I
submitted the patch to test the Content-Type.

AFAIK there's no reason not to remove the method test altogether; use
those bytes for something more useful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/camping-list/attachments/20070928/d90429e5/attachment.bin 

From _ at whats-your.name  Sat Sep 29 08:50:47 2007
From: _ at whats-your.name (cdr)
Date: Sat, 29 Sep 2007 08:50:47 -0400
Subject: PUT (and friends) bug?
In-Reply-To: <20070929012357.GB29057@nyarlathotep>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<20070929012357.GB29057@nyarlathotep>
Message-ID: <20070929125047.GA2732@replic.net>

> The @method == "post" test is a vestige of when Camping just parsed
> anything that was POSTed. I didn't really think about it when I
> submitted the patch to test the Content-Type.
> 
> AFAIK there's no reason not to remove the method test altogether; use
> those bytes for something more useful.

agreed. you can handle request body -> @input for any method except the ones that explicitly forbid request bodies (GET, HEAD, OPTIONS/TRACE?..), in one swoop.

the MIME test must stay, of course. otherwise when you add support for other MIMEs using #service it silenty fails trying to parse JSON or whatever as QSVars..


> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

From zimbatm at oree.ch  Sun Sep 30 16:27:45 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Sun, 30 Sep 2007 22:27:45 +0200
Subject: PUT (and friends) bug?
In-Reply-To: <20070929125047.GA2732@replic.net>
References: <4ce336a20709281222m6d2ad870jeca11424ea52db0c@mail.gmail.com>
	<20070929012357.GB29057@nyarlathotep>
	<20070929125047.GA2732@replic.net>
Message-ID: <e3caf1460709301327j79ce881ybca46cf7b5b5b5ef@mail.gmail.com>

Okay, I'll remove the test then.

-- 
Cheers,
  zimbatm