Sterling Hughes wrote:
It offers not one practical advantage.
I though the same, the SQLite euphoria should not be taken too far.
+1 for removing the SQLite Session Save Handled from the default
distribution.
-1
Corporate types won't be using this for session management. I guess the majority
of people that'll "try" this, is the home-grown developers. It's a nice addition
to session handling; and I feel it's premature to just remove it.
As Wez said, it's only been in the repo a day. It hasn't matured enough, and
we're still in the beta stage. Let's wait for feedback and and user flame
wars until this is removed? :)
Elfyn
Sterling Hughes wrote:
It offers not one practical advantage.
I though the same, the SQLite euphoria should not be taken too far.
+1 for removing the SQLite Session Save Handled from the default
distribution.-1
Corporate types won't be using this for session management. I guess the majority
of people that'll "try" this, is the home-grown developers. It's a nice addition
to session handling; and I feel it's premature to just remove it.As Wez said, it's only been in the repo a day. It hasn't matured enough, and
we're still in the beta stage. Let's wait for feedback and and user flame
wars until this is removed? :)
But again. WHY? Explain to me one case where they are useful?
The short answer is they aren't. I can write a cURL session handler
that uses HTTP PUT and HTTP GET. It might even be faster than SQLite
:) But its not useful. It provides no practical advantage, so why
should it be there by default? It shouldn't. PEAR is the appropriate
place for garbage^M^M^M^Mcode like this.
-Sterling
Elfyn
--
"Nothing is particularly hard if you divide it into small jobs."
- Henry Ford