On 8 Jan, 2006, at 6:59 pm, [EMAIL PROTECTED] wrote:
I'm wondering what leads you to say this, since this isn't the case
with any cookies or browsers in my experience. The fact that
clear_cookie() in visit.py wouldn't work if this were the case
makes me
think I must be misunderstanding you.
I don't think I've been entirely clear (obviously, or there wouldn't
still be discussion, or at least we'd have moved on from cookies).
Set your browser to confirm each cookie (Safari doesn't have this
option). Right now you'll only be asked about the first visit cookie.
If we were to try to keep all the necessary information in the
cookie, we'd need an expiry encoded in the cookie (this is how
Identity originally worked). However, because we can't update the
cookie without having the browser ask the visitor to confirm the
cookie again, the expiry encoded in the cookie will eventually pass
and your visit will expire -- even if your last page loaded was
seconds before.
Therefore, cookies are a write-once read-many solution (or actually
write-really-few read-many).
Traditionally, the solution to this problem is to store information
about the visit in RAM (think the standard ASP or JSP session). But
that doesn't work too well if you have a multi-process or multi-
server environment, because those processes or servers must share
memory (not impossible, but it drives up the cost of clustering
significantly).
A more robust solution is to store this information in a shared
database. It also provides for sessions (or visits) which can span
reboots of a server (which happens all the time under Windows).
my opinion is that hitting the db 2
or 3 times per request for visit tracking alone is neither necessary
nor ok
Visit tracking executes only 1 SELECT for each request. If this is
the first request of the visit or if the visit has expired, an
additional INSERT will occur to create a new visit record.
Periodically (every 30 seconds by default) the updated expiry for
each active visit will be written: 1 UPDATE for each visit that has
been active during this period.
Additionally, Identity executes 1 SELECT for each request plus
another request if a user is logged in.
Both of these SELECTs would normally hit the cache, but as I
understand it, SQLObject's caching is problematic. And it a real
system, you wouldn't incur the cost of either SELECT hitting your
database.
You can do
exactly what the current visit module does without touching the db at
all, with all data in the cookie
What you are proposing is EXACTLY what the Identity framework did
(except it didn't update the expiry in the cookie because of the
confirmation problem mentioned above) prior to revision 386. I'm very
familiar with the notion of signed cookies.
The bottom line is: If you think the guaranteed 2 SELECTs and one one-
hundredth of a second per request added by Visit tracking and
Identity are too much for your application, turn them off.
I believe that by the time TurboGears developers are starting to
worry about 2 SELECTs, they know the environment well enough to tune
it by turning off the features they don't need.
I'd rather give new developers access to all the tools and have them
work right out of the box. That's what attracted me to TurboGears in
the first place: it worked right out of the box without an hour or
two of XML push ups.
--
Jeff Watkins
http://newburyportion.com/
"Computers are like Old Testament gods; lots of rules and no mercy."
-- Joseph Campbell
