> -----Original Message----- > From: Jim Davis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 21, 2005 10:16 AM > To: CF-Talk > Subject: RE: terms: shared scope variables vs. persistent scope variables? > > > -----Original Message----- > > From: Johnny Le [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 21, 2005 10:07 AM > > To: CF-Talk > > Subject: Re: terms: shared scope variables vs. persistent scope > variables? > > > > So, Sean, if they are not "persistent", then all scopes (session, > > application, server, cookie) are "shared" scope? So "shared" here means > > sharing among requests and not among users?
As a last shot here: CF doesn't, at the application framework level, really have the concept of a "user". Session and Client variables come close, but they are just linked via a token value (which can, for nearly all conversation be called a "user" token without getting into trouble). But Session variables are not shared for a user - they have the additional filter of application. To get at "your" session the request has to declare itself a member of a specific application AND be given your session token - only then can you see the values in that session. Also this is all, really, just smoke and mirrors in a way. The various memory-resident scopes are truly all data structures sitting in the same RAM space. Essentially (I've no idea what happens under the covers) CF looks at the current request and creates pointers to things. So there are (sorta, kinda) rules like this: 1) This request is on a server! I'm going to create a pointer in this request to the "Server" scope information. 2) This request has told me it's part of an application! I'm going to create a pointer to that application's "Application" scope information. 3) This request has told me it's part of an application AND I see it has provided a session token! I'm going to create a pointer to that session token's "Session" scope information. This is done automatically by CF, but you can also (just to get confusing) link these scopes amongst one another. Do this in a request, for example: <cfset Application.Sessions[SessionToken] = Session> Well... now session scope information is available (via a pointer) in the application scope. By the same token you could link the Application scope to the Server scope or the Server to the Session scope and so forth - they're all just general data buckets. There's no information that you can place in the Session scope that you can't place in the Application or Server scopes (or vice versa). There's no real difference between them - the difference is in how CF exposes them based on its interpretation of the current request. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:210106 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
