The hdsInfo Class
Under the Dissemino regime, user sessions and cookies always have a direct one-to-one relationship. Cookies are only issued upon creation of a user session and users are limited to a single session. The term 'user' is this context, requires qualification. A user session is created when a registered user authenticates but a user does not have to be registered. Session are created by form handlers. If an <xformHdl> tag has the 'ops' attribute equal to 'cookies', the form handler will create a session and issue a cookie unless a session is already in place (by virtue of an earlier form submission). This can be for any purpose such as user registration and shopping carts. In the latter case the session keeps track of the selected items. It is only necessary to identify as an existing customer or become a new one at the checkout page. A 'user' in this wider sense, is a visitor to whom a cookie has been issued.
Not all form handlers will create sessions. The 'contact-us' page for example, does not necessarily create a session if all it does is accept comments and enquiries from anyone and does not seek to verify email addresses. If however email addresses are verified by sending a code to be typed in to complete the submission, a session will be created and a cookie will be issued.
User sessions are instances of the hdsInfo (Dissemino Infomation) class. Because of the HTTP and IP server class regimes, hdsInfo must necessarily be a derivatine of hzHttpSession, so it is defined as such. hdsInfo has the following members of interest:-
m_Sessvals | 1:1 Map of strings to atomic values (for any purpose). Note these are are set by 'setvar' instructions in form handlers and subsequently accessed by s-class percent entities. |
m_Objects | List of open data objects |
m_pTree | Pointer to user nav tree (if applcable) |
m_pObj | Pointer to current object |
m_pMisc | Application specific void* pointer |
m_Username | (String) Username as per subscriber repository |
m_Access | Controls what the user will see (pages and parts of pages) |
m_SubId | Unique subscriber ID (object id) of user in the subscriber cache (Only non-zero if a registered user is logged in) |
m_UserId | Unique ID (object id) of user (for lookup in the cache) |
m_CurrObj | The current data object (if any). An hdbObject can also be imported and xported as a JSON form/to a specific user file. The values in the current object are accessed by v-class percent entities. |
m_UserRepos | User repository id (if registered user) |
m_CurrRepos | Current repository (if any) |
m_CurrClass | Current class (within repos) |
Dissemino Stats
Without a user session, the HTTP client is known in the parlance as a 'visitor' i.e. The browser operator is only visting the site to read content, not performing actions. Visitors are tracked only on the basis of their IP address. Each visitor is assigned a hdsProfile instance which they keep even if they are subsequently assigned a user session. This holds the aggregate total requests of each visitor. This information allows webmasters to see at a glance, which users are robots and which are human. hdsProfile records the following:-
m_addr | IP address of client |
m_art | GET 200 - Articles requested |
m_page | GET 200 - Pages requested |
m_robot | GET 200 - Number of requests for robot.txt |
m_favicon | GET 200 - Number of requests for favicon.ico |
m_scr | GET 200 - Scripts requested |
m_img | GET 200 - Images requested |
m_spec | GET 200 - Special requests |
m_fix | GET 200 - Fix page requests |
m_G404 | GET 404 - non-existant resources requested |
m_post | POST OK Form submissions |
m_P404 | POST FAIL, Non-existant resources requested |
m_bFlags | Misc flags |