On Tue, 2003-07-01 at 16:33, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 04:00 PM, Sterling Hughes wrote:
> > On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
> >> On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
> >>
> >>
> >> This is no different than a typical mysql setup using myisam
> >> datafiles.
> >>
> >
> > Is mysql session handling bundled? Talking about prior art, postgresql
> > sessions weren't included. Also, there is a much bigger advantage to
> > using postgresql sessions than sqlite sessions.
>
> No, but I addressed the principal difference between those in my mail.
That they aren't bundled? Sure. But that doesn't mean they couldn't be
included when they are enabled. SQLite sessions gain you nothing.
>
> >>> 2) It offers not one practical advantage. When asking the proponents
> >>> of
> >>> SQLite based sessions, they said the advantage is that everything is
> >>> in
> >>> one file.
> >>>
> >>> That's the disadvantage.
> >>
> >> It's also an advantage from the standpoint of cleanliness and
> >> manageability. The ability to identify and whack a session out of
> >> band
> >> is nice. The biggest possible advantage is that it's a builtin
> >> endorsement for sqlite which you lobbied hard for enabling by default
> >> just days ago.
> >>
> >
> > What do you mean (re the first)? You can remove files just as easily.
> >
> > rm -f /tmp/sess_id
> > or
> > rm -f /tmp/sess_*
> >
> > versus what?
> >
> > rm -f /tmp/sessions
>
> You can query,modify your session information in a natural way. That's
> very valuable.
Can you? Show me how. What about if this is installed on a shared
host? Then I could also query *your* session information as well. ;)
So we agree then that its only suitable when using your server (virtual
server, whatever). In that case performance generally matters somewhat,
and you wouldn't subject yourself to such a slowdown. Also, its not
that hard to query session information with files, on the odd chances
they are needed.
Sessions shouldn't be queryable in the first place. Its not a reliable
method (different serialization and encryption formats), and it can be a
security vulnerability. Also, show me a real world php application that
actually goes ahead and queries sessions.
>
> > Again. Code shouldn't be added because it can be added. There is no
> > advantage to using SQLite sessions, so why have them by default? its a
> > trivial php implementation if someone really wants to use it. My point
> > is that there is further no advantage to having them written in C (like
> > it would be for a rot13 function to improve speed).
>
> It's entirely different. It provides some features that files do not
> (despite your unwillingness to listen to others on that).
>
Like? What is the practical advantage? I see the validity in using SQL
interfaces to sessions in the ability to integrate them with a
pre-existing infrastructure - this most often requires custom
development. Using these sessions don't allow you to even integrate
with pre-existing infrastructures.
> George
>
>
> p.s. Henry Ford is an interesting role model. His bull-headed ideas
> catapulted Ford to the top of the burgeoning automobile industry, but
> his unwillingness to reconcile his own image of what people wanted and
> would use also lead to Ford falling so seriously behind the market that
> they are still trying to catch up today. He was also a real enemy of
> organized labor, but that's another story.
I've attached a more appropriate quote for your enjoyment :)
--
Good judgement comes from experience, and experience comes from
bad judgement.
- Fred Brooks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
