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.
Hi Daniel, I like the idea pretty much. What do you think of simply using a Camping::H that is process-persistent ? -- Cheers, zimbatm
On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote:> I like the idea pretty much. What do you think of simply using a > Camping::H that is process-persistent ?Sure, and maybe it doesn''t really need to be process-persistent. Yes, that would be how Camping would want us to do it. _why
> Sure, and maybe it doesn''t really need to be process-persistent.Wouldn''t that limit you to non-load-balanced apps, since you could only have one simultaneous process if you want session consistency? Evan On 10/5/07, why the lucky stiff <why at whytheluckystiff.net> wrote:> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > I like the idea pretty much. What do you think of simply using a > > Camping::H that is process-persistent ? > > Sure, and maybe it doesn''t really need to be process-persistent. > Yes, that would be how Camping would want us to do it. > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Evan Weaver Cloudburst, LLC
On Oct 5, 2007, at 3:54 PM, Evan Weaver wrote:>> Sure, and maybe it doesn''t really need to be process-persistent. > > Wouldn''t that limit you to non-load-balanced apps, since you could > only have one simultaneous process if you want session consistency? > > Evan >Can always make it easy and well-defined to override. s/H/DHT with the right API/ and let ''em go.
2007/10/5, why the lucky stiff <why at whytheluckystiff.net>:> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > I like the idea pretty much. What do you think of simply using a > > Camping::H that is process-persistent ? > > Sure, and maybe it doesn''t really need to be process-persistent.How can it be less than process-persistent ? Instance persistent ? Or is it irony and it means not persistent at all ? :p -- Cheers, zimbatm
On 7-okt-2007, at 18:55, Jonas Pfenniger wrote:> 2007/10/5, why the lucky stiff <why at whytheluckystiff.net>: >> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: >>> I like the idea pretty much. What do you think of simply using a >>> Camping::H that is process-persistent ? >> >> Sure, and maybe it doesn''t really need to be process-persistent. > > How can it be less than process-persistent ? Instance persistent ? Or > is it irony and it means not persistent at all ? :pAs mentioned previously, you have cliented sessions with signing - but then you are limited to the cookie size minus the signature. Personally I''m all for different session drivers - some kind of agreement what a session should and sould not do perhaps? Then you can plug session/cookies, session/files or session/db at your heart''s content. The thing of note is that I think it should be configurable per app (because some apps have different session size requirements, and some apps would not want to reveal the session content in a cookie). -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
I took it to mean "persistent across processes" not "persistent per-process". Evan On 10/7/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:> 2007/10/5, why the lucky stiff <why at whytheluckystiff.net>: > > On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > > I like the idea pretty much. What do you think of simply using a > > > Camping::H that is process-persistent ? > > > > Sure, and maybe it doesn''t really need to be process-persistent. > > How can it be less than process-persistent ? Instance persistent ? Or > is it irony and it means not persistent at all ? :p > > -- > Cheers, > zimbatm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Evan Weaver Cloudburst, LLC
> Personally I''m all for different session drivers - some kind of > agreement what a session should and sould not do perhaps? > Then you can plug session/cookies, session/files or session/db at > your heart''s content. The thing of note is that > I think it should be configurable per app (because some apps have > different session size requirements, and some apps would > not want to reveal the session content in a cookie).I agree; a suite of session drivers would be a useful addition. If no one else steps up, eventually I would be able to write them, but I am very busy right now and don''t have an immediate need for different session types. All right, back to the woods. Evan -- Evan Weaver Cloudburst, LLC