Cookies may be transmitted to the client to be stored (however the client browsers do it) on the client machine. Then, they may be read back by the CloudWriter program at a later time.
A cookie is a small hierarchical database constructed by the CloudWriter program and stored on the client machine. The cookie would generally contain data specific to the application and the particular client that would need to be used by another CloudWriter program or another page. For example, cookies could be used to store a shopping cart on the client.
The cookie is stored on the client by the WriteCookie function. When an CloudWriter application starts, any cookies associated with the application are read from the client and instantiated as a table called "_Cookie".
Write a cookie using the WriteCookie function:
bool WriteCookie (string Name, any Value, string Expires, string Path, string Domain, bool secure);
The cookie table contains pairs of names (keys) and values.
The Value variable may be a simple scalar variable, a table, or an array. If it is a table or array, we have, in effect, a hierarchical cookie database. Values in the table may be simple variables or may themselves be tables or arrays.
The Expires variable specifies the expiration date of the cookie. If the Expires variable is not set, the cookie is a session variable that is only valid until the browser window is closed. If the Expires variable is set, the cookie is a persistent variable. The following table shows the expiration date format.
Format |
Description |
| DD-MMM-YYYY HH:MM:SS GMT | Complete format |
| DD | DD is the day in the month—such as 01 for the first day of the month. |
| MMM | MMM is the three-letter abbreviation for the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec). |
| YYYY | YYYY is the year. |
| HH:MM:SS GMT | HH is the hour value in military time (22 would be 10:00 P.M., for example), MM is the minute value, and SS is the second value. |
Specifying the domain, is optional for persistent cookies and is used to indicate the end of the domain for which the cookie is valid. Session cookies that specify a domain are rejected. If the specified domain name ending matches the request, the cookie tries to match the path to determine if the cookie should be sent. For example, if the domain name ending is .microsoft.com, requests to home.microsoft.com and support.microsoft.com would be checked to see if the specified pattern matches the request. The domain name must have at least two or three periods in it to prevent cookies from being set for widely used domain name endings, such as .com and .edu. Acceptable domain names would be similar to .microsoft.com, .someschool.edu, and .someserver.co.jp. Only hosts within the specified domain can set a cookie for a domain.
Setting the path variable is optional and can be used to specify a subset of the Uniform Resource Locators (URLs) for which the cookie is valid. If a path is specified, the cookie is considered valid for any requests that match that path. For example, if the specified path is /example, requests with the paths /examplecode and /example/code.htm would match. If no path is specified, the path is assumed to be the path of the resource associated with the Set-Cookie header.
The cookie can also be marked as secure, which specifies that the cookie can be sent only to HTTPS servers. The default value for Secure is false.
x = new table;
x["always on"] = "false";
x["Name"] = Name;
x["Email"] = Email;
WriteCookie("Preferences", x, "31-DEC-2001 00:00:00 GMT", "", "", 0);
Now, in a later session we can retrieve the data in the cookie like this:
x = _Cookie["Preferences"];
John Elkins (john@vermontdatabase.com) 11-2-2000