UNSUBSCRIBE
On Oct 5, 2007, at 1:27 PM, camping-list-request at rubyforge.org wrote:
> Send Camping-list mailing list submissions to
> camping-list at rubyforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://rubyforge.org/mailman/listinfo/camping-list
> or, via email, send a message with subject or body ''help''
to
> camping-list-request at rubyforge.org
>
> You can reach the person managing the list at
> camping-list-owner at rubyforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Camping-list digest..."
>
>
> Today''s Topics:
>
> 1. Re: putting away HashWithIndifferentAccess (Jonas Pfenniger)
> 2. Re: PUT (and friends) bug? (Brendan Taylor)
> 3. Re: PUT (and friends) bug? (cdr)
> 4. Re: PUT (and friends) bug? (Jonas Pfenniger)
> 5. Session handling busted on Oracle (Berger, Daniel)
> 6. Cookie session handling? (Berger, Daniel)
> 7. Re: Session handling busted on Oracle (Jonas Pfenniger)
> 8. Re: Cookie session handling? (Jonas Pfenniger)
> 9. Re: Session handling busted on Oracle (Julian
''Julik'' Tarkhanov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 29 Sep 2007 01:16:18 +0200
> From: "Jonas Pfenniger" <zimbatm at oree.ch>
> Subject: Re: putting away HashWithIndifferentAccess
> To: camping-list at rubyforge.org
> Message-ID:
> <e3caf1460709281616n464cdfaei61e67ce220ad167b at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Fri, 28 Sep 2007 19:23:57 -0600
> From: Brendan Taylor <whateley at gmail.com>
> Subject: Re: PUT (and friends) bug?
> To: camping-list at rubyforge.org
> Message-ID: <20070929012357.GB29057 at nyarlathotep>
> Content-Type: text/plain; charset="us-ascii"
>
> 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-0001.bin
>
> ------------------------------
>
> Message: 3
> Date: Sat, 29 Sep 2007 08:50:47 -0400
> From: cdr <_ at whats-your.name>
> Subject: Re: PUT (and friends) bug?
> To: camping-list at rubyforge.org
> Message-ID: <20070929125047.GA2732 at replic.net>
> Content-Type: text/plain; charset=us-ascii
>
>> 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
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 30 Sep 2007 22:27:45 +0200
> From: "Jonas Pfenniger" <zimbatm at oree.ch>
> Subject: Re: PUT (and friends) bug?
> To: camping-list at rubyforge.org
> Message-ID:
> <e3caf1460709301327j79ce881ybca46cf7b5b5b5ef at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Okay, I''ll remove the test then.
>
> --
> Cheers,
> zimbatm
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 5 Oct 2007 08:38:57 -0500
> From: "Berger, Daniel" <Daniel.Berger at qwest.com>
> Subject: Session handling busted on Oracle
> To: <camping-list at rubyforge.org>
> Message-ID:
> <7524A45A1A5B264FA4809E2156496CFBE72E73 at
ITOMAE2KM01.AD.QINTRA.COM>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> Ruby 1.8.6 (one-click)
> Camping 1.5
>
> I''d submit this as a bug, but the tracker says I''m
forbidden, so here
> you go.
>
> The first problem is that the sql to create the sessions table is
> broken. This is what it tried to send:
>
> CREATE TABLE sessions (
> id NUMBER(38) NOT NULL PRIMARY KEY (38), --> Problem here
> hashid VARCHAR2(32),
> created_at DATE,
> ivars CLOB DEFAULT empty_clob()
> )
>
> The problem is that second "(38)" after "PRIMARY KEY".
So, I removed
> that and created the table manually.
>
> The next problem was a missing Oracle sequence (which I had no idea
> was
> required, but ok). I figured out (by stepping through oci8.rb) that
> the
> name of the sequence should be "sessions_seq". For that I used
the
> following snippet:
>
> CREATE SEQUENCE ACS_SUPPORT.SESSIONS_SEQ
> START WITH 50
> MAXVALUE 999999999999999999999999999
> MINVALUE 0
> NOCYCLE
> CACHE 50
> NOORDER;
>
> Unfortunately, there are still problems, and here''s where
I''m not sure
> what''s happening:
>
> [2007-10-04 15:53:24] INFO WEBrick 1.3.1
> [2007-10-04 15:53:24] INFO ruby 1.8.6 (2007-03-13) [i386-mswin32]
> [2007-10-04 15:53:24] INFO WEBrick::HTTPServer#start: pid=1736
> port=3301
> [2007-10-04 15:53:31] ERROR NoMethodError: undefined method `[]=''
for
> nil:NilClass
>
> C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:
> 21:in
> `[]=''
>
> C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:
> 110:in
> `service''
> (eval):44:in `run''
>
> C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/reloader.rb:
> 117:i
> n `run''
>
> C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/webrick.rb:
> 45:in
> `service''
> C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in
`service''
> C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:173:in
`start_thread''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in
`start_thread''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:95:in `start''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `each''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `start''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:23:in `start''
> C:/ruby/lib/ruby/1.8/webrick/server.rb:82:in `start''
> C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/bin/camping:244
> C:/ruby/bin/camping:16:in `load''
> C:/ruby/bin/camping:16
>
> So, for whatever reason, it''s not pulling the sessions_seq.nextval
> properly. At least, that''s my guess. I haven''t debugged
further as I
> sorta lost energy at that point.
>
> Any ideas?
>
> Regards,
>
> Dan
>
>
> This communication is the property of Qwest and may contain
> confidential or
> privileged information. Unauthorized use of this communication is
> strictly
> prohibited and may be unlawful. If you have received this
> communication
> in error, please immediately notify the sender by reply e-mail and
> destroy
> all copies of the communication and any attachments.
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 5 Oct 2007 09:08:16 -0500
> From: "Berger, Daniel" <Daniel.Berger at qwest.com>
> Subject: Cookie session handling?
> To: <camping-list at rubyforge.org>
> Message-ID:
> <7524A45A1A5B264FA4809E2156496CFBE72E76 at
ITOMAE2KM01.AD.QINTRA.COM>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I and a few folks on #camping thought it would be nice to have either
> cookie based or file based session handling. This would eliminate the
> need for creating a sessions table in the database (or a sequence),
> which feels too heavy for a lightweight framework like Camping anyway.
> Plus, we can more easily avoid nasty adapter errors. :)
>
> The general consensus was to create a separate camping/session/
> cookie.rb
> (or file.rb) file. That way users could include the type of session
> handling they want via require + include.
>
> require ''camping/session/cookie''
>
> module MyCamp
> include Camping::Session::Cookie # or File, or whatever
> end
>
> Or something along those lines. Whaddya think?
>
> Regards,
>
> Dan
>
>
> This communication is the property of Qwest and may contain
> confidential or
> privileged information. Unauthorized use of this communication is
> strictly
> prohibited and may be unlawful. If you have received this
> communication
> in error, please immediately notify the sender by reply e-mail and
> destroy
> all copies of the communication and any attachments.
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 5 Oct 2007 17:54:26 +0200
> From: "Jonas Pfenniger" <zimbatm at oree.ch>
> Subject: Re: Session handling busted on Oracle
> To: camping-list at rubyforge.org
> Message-ID:
> <e3caf1460710050854s7fce649crfec23590a953c9e9 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Daniel,
>
> I think that I have corrected that last week changeset [226]. The
> problem was that Session uses it''s own kind of id (hashid) and
that by
> default, ActiveRecord uses an incremental version.
>
> See : http://code.whytheluckystiff.net/camping/changeset/226
>
> Please tell me if I introduced any regression.
>
> --
> Cheers,
> zimbatm
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 5 Oct 2007 18:08:12 +0200
> From: "Jonas Pfenniger" <zimbatm at oree.ch>
> Subject: Re: Cookie session handling?
> To: camping-list at rubyforge.org
> Message-ID:
> <e3caf1460710050908o6f495c1bm762595675a3d82f3 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Daniel,
>
> I like the idea pretty much. What do you think of simply using a
> Camping::H that is process-persistent ?
>
> --
> Cheers,
> zimbatm
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 5 Oct 2007 19:27:37 +0200
> From: Julian ''Julik'' Tarkhanov <julian.tarkhanov at
gmail.com>
> Subject: Re: Session handling busted on Oracle
> To: camping-list at rubyforge.org
> Message-ID: <6D239BF7-74A3-4584-B7A6-A485F9702A01 at gmail.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On 5-okt-2007, at 17:54, Jonas Pfenniger wrote:
>
>> I think that I have corrected that last week changeset [226]. The
>> problem was that Session uses it''s own kind of id (hashid) and
>> that by
>> default, ActiveRecord uses an incremental version.
>>
>> See : http://code.whytheluckystiff.net/camping/changeset/226
>>
>> Please tell me if I introduced any regression.
>
> I am for the proposal of having multiple session drivers, but totally
> _not_ for the proposal of abolishing
> the db sessions. I routinely run Camping in parallel fashion
> (multiplexed dispatchers) and I also store
> data that does not fit in the 4K cookie limit in the session (see
> Pasaporte, where the whole OpenID request
> is piggybacked in the session storage). I also like the idea that all
> Camping apps store their session in _one_ record,
> with many apps on one domain this would not be easily solvable
> because 4k is too small for one app, let alone many apps.
> So I am for a PStore-based session but not for cookie-based sessions.
> Their introduction in Rails among others revealed some problems that
> exist with this approach.
>
> The changeset did not introduce any regressions for me but I will
> keep my Set-Cookie workaround for a while, at least until Camping 1.6
> hits the streets
>
> --
> 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
>
> End of Camping-list Digest, Vol 18, Issue 1
> *******************************************
