Client vs Session vs Cookie Variables

[ProjectedSurplus]

Long story short I am creating a web site which adjusts its GUI based on the visitors IP. Ideally the visitor can then modify these settings and have these choices "remembered" by the site on next visit. As I understand it, if I save these settings in:

COOKIE.VAR then this info passes back and forth on every page request (which i don't want)
SESSION.VAR then this info takes up server memory (which I don't want)
CLIENT.VAR then this info resides in a dbase (as selected in cfadmin to replace server registry default)

So, in this instance client.var seems the way to go BUT it only holds simple values (the GUI now is a query result/array of text filenames) so I would need to serialize?/fromList()??/toString()??? the info.

Similarly, I would think that should the user choose the "Remember Me" login option it would be better to store his username and password in CLIENT.vars rather than as an unsecure cookie on his/her machine.

Thanks in advance for thoughts or comments???

[ProjectedSurplus]

As a further point, at present I have a <cfinvoke> at the top of my index page which calls the component -- but without using frames (for reasons of my own) this infers that literally every page calls the IP-to-GUI component everytime.

I have learned that flash/flex has the ability to store the data in a shared object (and then only send the info when instructed to do so vs. with every request like a cookie.var does).

Ideally though in HTML (too fwiw) I only want to invoke this component on first visit or on change. I'm currently reading up on the onSessionStart method of the Application.cfc file ("This is a special method run only at the beginning of a user's session. Conversely, it may be handy to notice when a user's session end via onSessionEnd method") with thoughts of writing the cookie onSessionEnd and reading&deleting onSessionStart.

Thoughts??

[ProjectedSurplus]

Or, what about using the onRequestStart or onRequest methods of Application.cfc?

Another thought is to use the cgi.HTTP_referer to determine if visitor is coming from outside (hence in need of ip-to-GUI component) OR if they are coming from another page of mysite (and hence not in need of a new trip to that cfc/dbase if the info is already available in say a client variable)

Anyone with any experience in this sort of thing?

[Newsgroup_User]

You may be over thinking this.

Why don't you want to use session variables. Most people *want* to put
as much into memory as possible to eliminate as much database and file
system calls as possible. Obviously this needs to be balanced with
system capabilities and site traffic, but in general memory is better
then database is better then file IO.

The way this is usually done is that a cookie value is used to store a
user ID. This ID is then used to retrieve user state from a permanent
store of your choice. Placing this data into session memory during the
visit of the user.

[ProjectedSurplus]

Not to sound like a smart ass but there is no doubt I am overthinking this (you wouldn't believe how much difficulty I have deciding what to wear each morning ;).

Nonetheless, I am truly concerned about scalability etc (I have an excel spreadsheet showing how fast we'll be at 8 billion members if you want to see it 😉 and don't see the desirability of putting fairly unimportant GUI data (header = red etc) into server memory.

On the other hand though I have little practical experience in actually running a site (feel free to condemn my over thinking now out loud) and realize that even a Gb of memory can hold enormous amounts of text = value) so . . . .

That said -- and let me emphasize I am sincerely appreciative of your knowledgeable feedback on this and other posts -- do you still think I should just put this stuff into a SESSION.var (which I realize can be a struct) ? If so then I guess I would only call the cfc (to lookup new GUI info from the dbase) if that SESSION.var is changed or not there?

[Newsgroup_User]

> That said -- and let me emphasize I am sincerely appreciative of your
> knowledgeable feedback on this and other posts -- do you still think I should
> just put this stuff into a SESSION.var (which I realize can be a struct) ? If
> so then I guess I would only call the cfc (to lookup new GUI info from the
> dbase) if that SESSION.var is changed or not there?

That would be my first plan. Generally speaking you do not want to make
a database call every request. That is harder on the server. You still
need that data in memory. So you really are speaking about the life
span of that data in memory.

In a get it every request plan, it will go into the memory for the life
span of the request. While this will be a very short time, it does not
go away immediately at the end of the request. While the memory will be
cleared for garbage collection, that may not happen for quite some time
(in computer time). So if you have 8 billion members, actively visiting
your site, creating a new structure of their preferences with every
page. That can add up fast.

By loading their preferences once, when they first visit the site each
session, and then using this data until they are done will probably be
much less memory. A performance metric you will want to keep your eye
on is how long the session lives. You do not want it to live too long
after they finish their visit.

Unfortunately the stateless nature of the HTTP protocol means that the
client never tells your server when it is closed or goes to another
site. So you will want your session time-out to be a high enough value
that people can move freely around your site without hassle, but low
enough that a bunch of old data does not hang around longer then needed.

The default 20 minutes is generally consider a very long time. Probably
relevant to low-use corporate intranet applications where a user may be
using a web application all day long. But awfully long for a general
internet web site; where users, usually, go from page to page fairly
quickly until they are done.

In summary you are really considering between a plan that will use
[number of users * size of GUI data * number of pages they visit] versus
one that is just [number of users * size of GUI data].

[ProjectedSurplus]

Yes, definitely NOT a repeat every request strategy.

However, what is the root of the issue is that I want to remember the user's settings upon their next visit.

As such don't I still need to write the info to either a CLIENT.var or a COOKIE.var upon session end?

(To me doing so would both allow remembering of visitor choices and reduce dbase pings)

[Newsgroup_User]

ProjectedSurplus wrote:
> Yes, definitely NOT a repeat every request strategy.
>
> However, what is the root of the issue is that I want to remember the user's
> settings upon their next visit.
>
> As such don't I still need to write the info to either a CLIENT.var or a
> COOKIE.var upon session end?
>
> (To me doing so would both allow remembering of visitor choices and reduce
> dbase pings)
>

Yes, something would need to be written to a cookie. You could store
the entire data set if you choose. There are challenges but they are
not unsurmountable. There are also some limits The solution would
depend somewhat on how much data you want to store.

For a few simple keys and values you could just make a separate cookie
for each. Otherwise you could serialize a complex variable either
manually or with something like the <cfwddx...> tag.

The latter is very hand, but rather verbose, so if you are working with
a lot of data you may want something leaner so that you don't run into
problems with maximum cookie size, which was about 4K if I recall
correctly and has not changed since I last paid attention to it.

But personally, making a single database call once each time a visitor
starts a session against a well defined and optimized database is not
very stressful on a system.

It may be relevant that one way or another cookies are going to be used.
Whether you manage them and their content or not -- cookies are the
*only* way to maintain user state between http requests. Either you
create them or ColdFusion will if you go with a straight forward client
or session scope for your data scope.

[ProjectedSurplus]

So, just to confirm, EVERY cookie.var is sent with every browser request, right (ie not just when called/referenced)? As in a previous post, I understand Flash/Flex enables shared objects stored on the client which are not transmitted unless specified.

Assuming there is no direct way to have similar functionality in HTML, the next best way to do what I seek (which btw is not involved with my intention to manage user state in a more forward Session var) is to write a CLIENT var onSessionEnd and only read that info onSessionStart (or when changed by the visitor).

[Newsgroup_User]

ProjectedSurplus wrote:
> So, just to confirm, EVERY cookie.var is sent with every browser request, right
> (ie not just when called/referenced)? As in a previous post, I understand
> Flash/Flex enables shared objects stored on the client which are not
> transmitted unless specified.
>
> Assuming there is no direct way to have similar functionality in HTML, the
> next best way to do what I seek (which btw is not involved with my intention to
> manage user state in a more forward Session var) is to write a CLIENT var
> onSessionEnd and only read that info onSessionStart (or when changed by the
> visitor).
>
>
>

Yes with standard HTTP, every cookie belonging to a domain is included
with every request sent to that domain. That is just the way they work.

I'm not sure that client is much of an option here. At least it is no
different then the other plans under consideration. Because with Client
variable you only have three choices on where you can store the data.

In the system registry or some facsimile there of. And this is a bad,
bad, bad thing to do. It is the default, because it is the only choice
that can be guaranteed to work 'out of the box'. But is generally
considered the worse choice and has the very real possibility to fill
the registry with data and bring the entire server down. This warning
is in the documentation which strongly recommends not using this
solution on anything but the smallest application.

So that just leaves the other two choices, storing the client data in
cookies, no different then any other cookies. Or a database, no
different then any other database connection.

So you are still debating the pros and cons of storing this data on the
clients machine and have it sent back and forth over the network with
every request. Or in a database and have it read into memory whenever
the user visits the site.

Flex w/ Flash works differently because it is not stateless. The Flash
client opens and keeps open a connection to the server so state can be
maintained throughout the life of an application. None of the request,
response, forget cycle that needs to be worked around in normal HTTP
applications.