> Moon, John wrote:
> > Does anyone know if I should be able to write a cookie like :
> >
>
> [ snip complex data structure ]
>
> You can do this if you serialize the complex structure into a scalar and
> then deserialize it when you read the cookie back.
>
> For an example of how to do this see the module
> Apache::Session::Serialize::Base64. It uses Storable and MIME::Base64 to do
> the serialization. There are various other serialization modules on CPAN you
> might look into...
This entire thread segueues nicely to a discussion on "what should you
keep in a cookie?"
Lawrence's Cookie Dogma #1: Any site that has more than one opaque
identifier per user is B-R-O-K-E-N. ESPECIALLY sites that keep lots
and lots of state in a cookie.
Exceptions to LCD#1 include: Yeah, yeah, I know -- sometimes site
operators install some 3d party thing that needs it's OWN opaque
identifier, and then they find they have seven of these 3d party
modules, each with its own identity cookie ...
Some advantages to having state kept on the server side:
1 - I can connect from any computer in the world and my preferences
and state follow me. This is ESPECIALLY important for markets outside
the US, where some large fraction do all their web-surfing from
public-access computers.
2 - The amount of data you can safely store in a cookie is browser
dependent and variable.
3 - ALL cookie data (barring some clever hacks with paths) is
transmitted with EVERY request, increasing overall site latency.
Imagine how long it takes to send a dozen cookies of a few hundred
bytes each with EVERY request when the user is on a severely
asymmetrical connection. Now, multiply that delay through the
eleventy-three indivisual graphic elements on each of your pages, and
keep that in mind when the marketing people come ask you why so many
users only get one layer deep in the click-path.
4 - If the day comes, that you decide NOT to use cookies at all for
state, for marketing reasons[1], you're going to have to solve this
problem again.
Footnotes:
[1] I actually think cookie paranoia is misplaced, and would love to
see users educated -- but The Client Is Always Right, and if they say
"Our industry demands no cookies" then so be it. There are other ways
of keeping state, use them when you must.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
