[geeklog-devtalk] geeklog-devel digest, Vol 1 #386 - 4 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Sessions, again (Dirk Haun)
   2. Re: Sessions, again (Blaine Lang)
   3. Re: Sessions, again (Peter Roozemaal)
   4. Re: Sessions, again (Blaine Lang)

--__--__--

Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Sessions, again
Date: Sun, 5 Sep 2004 12:07:22 +0200
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,


>Regardless, I think the session handling in Geeklog is archaic at best 

>and needs revamping.


No doubts about that.



>I'm less pessimestic.  I think with all the changes and the 

>register_globals stuff we should take our time, call this release 1.4 

>and move on.


I'm not pessimistic, I was just annoyed.

I agree that Geeklog's session handling needs an overhaul. But this isn't
something that we should rush.

I agreed to adding the HTTP_Sessions code on the assumption that it
wouldn't break anything, but that turned out not to be the case. So I've
removed it from CVS again now and say we make that our #1 priority for
the next release after 1.3.10.



>If  you decide to rip it out of CVS, please give a heads up so I 

>can bring a copy down just prior.


It's only 3 lines of code anyway:

<http://cvs.geeklog.net/diff.php/geeklog-1.3/public_html/lib-common.php?
ws=0&r1=1.371&r2=1.372>



>I'm assuming the write you are seeing is when it is writing 

>the Session ID to the cookie, right?  That's the only thing I can think of.


Yep.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/


--__--__--

Message: 2
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Sessions, again
Date: Sun, 5 Sep 2004 11:14:03 -0400
Reply-To: geeklog-devel at lists.geeklog.net

Why don't we just use the core PHP Session functions - that was my original
intention all along.

There will still be a browser session based cookie.
SESSION Based files will be the current only option
We can have a Config Parm to disable sessions which can be off by default
for now

Blaine
----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Sunday, September 05, 2004 6:07 AM
Subject: Re: [geeklog-devel] Sessions, again


Tony,


>Regardless, I think the session handling in Geeklog is archaic at best

>and needs revamping.


No doubts about that.



>I'm less pessimestic.  I think with all the changes and the

>register_globals stuff we should take our time, call this release 1.4

>and move on.


I'm not pessimistic, I was just annoyed.

I agree that Geeklog's session handling needs an overhaul. But this isn't
something that we should rush.

I agreed to adding the HTTP_Sessions code on the assumption that it
wouldn't break anything, but that turned out not to be the case. So I've
removed it from CVS again now and say we make that our #1 priority for
the next release after 1.3.10.



>If  you decide to rip it out of CVS, please give a heads up so I

>can bring a copy down just prior.


It's only 3 lines of code anyway:

<http://cvs.geeklog.net/diff.php/geeklog-1.3/public_html/lib-common.php?
ws=0&r1=1.371&r2=1.372>



>I'm assuming the write you are seeing is when it is writing

>the Session ID to the cookie, right?  That's the only thing I can think of.


Yep.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


--__--__--

Message: 3
Date: Sun, 05 Sep 2004 18:13:55 +0200
From: Peter Roozemaal <mathfox at xs4all.nl>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Sessions, again
Reply-To: geeklog-devel at lists.geeklog.net

Blaine Lang wrote:

> Why don't we just use the core PHP Session functions - that was my

> original intention all along.

> 

> There will still be a browser session based cookie. SESSION Based

> files will be the current only option We can have a Config Parm to

> disable sessions which can be off by default for now


There are serious problems with the combination of session files and
load-balanced web servers. In essence, it requires a shared file server
and creates another point of failure. Database stored session info is
more natural for our setup.

Greetings,
	Peter.


--__--__--

Message: 4
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Sessions, again
Date: Sun, 5 Sep 2004 12:24:53 -0400
Reply-To: geeklog-devel at lists.geeklog.net

Peter wrote:

> There are serious problems with the combination of session files and

> load-balanced web servers.


Yes, that is true and I have clients that I used PHP SESSIONS in such an
environment and they typically do have the infrastructure to support SESSION
based files. The number of Geeklog installs that run in such an environment
are probally .001%.

Are we to not consider moving forward because this and we are not making any
core changes to require sessions at this time. I have GL based client
plugins that now use sessions and it obviously is a positive development.

I personally just think we should include the PEAR library as it's pretty
small for now.

I want to move forward not backward and we are not making any core changes
at this time to require sessions.
I suggest adding a $_CONF parm that is off by default. If enabled it will
load the PEAR class and initiate sessions.

Otherwise - let's use the PHP Sessions - again with the $_CONF parm.

Blaine
----- Original Message ----- 
From: "Peter Roozemaal" <mathfox at xs4all.nl>
To: <geeklog-devel at lists.geeklog.net>
Sent: Sunday, September 05, 2004 12:13 PM
Subject: Re: [geeklog-devel] Sessions, again


Blaine Lang wrote:

> Why don't we just use the core PHP Session functions - that was my

> original intention all along.

>

> There will still be a browser session based cookie. SESSION Based

> files will be the current only option We can have a Config Parm to

> disable sessions which can be off by default for now


There are serious problems with the combination of session files and
load-balanced web servers. In essence, it requires a shared file server
and creates another point of failure. Database stored session info is
more natural for our setup.

Greetings,
Peter.

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest