All due respect, but hat's a little condescending... I generally cringe
when I hear anyone advocating that there is one "right" way to do things
that should be used in every instance
In addition to Michael's points (which are totally valid) I would add
that your solution is great for small/medium sized sites but as soon as
you scale into sites with very large amounts of traffic it quickly
raises a lot of operational concerns about where to store that data in
place that's retrievable in a short enough time frame to not degrade
performance. Solving that problem is going to cost time and money and
will sometimes result in your application caring about session affinity,
which is another operational concern.
I'm not saying that these problems aren't solvable, I'm simply saying
that I don't think it's nearly as cut and dried as you seem to,
especially when you look at the app from and operational perspective.
I can see both sides of this argument and I can see situations in in
which either solution might be advantageous over the other. A lot
depends on budget, environmental layout, how often the session is
updated, how much data you're storing, etc... Perhaps you could outline
in a little more detail why you think storing everything server side is
the only "right" way to do things?
Randal L. Schwartz wrote:
"Michael" == Michael Peters <mpet...@plusthree.com> writes:
Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
cookies should really just be used to distinguish one browser from another,
and hold everything server-side instead for far better security and
flexibility.
Michael> I disagree. Using cookies for session data has a lot of advantages:
[justifications snipped]
Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter
webdev people always do. I sounded exactly like you, once, and then grew out
of it. The more you resist, the longer your delay. :)
