Why is persistent data a good thing?

When would I want to use persistent data?

What is the persistent data identifier? And how do I share data between applets?

How does security work with shared persistent data repositories?

From the applet writer's point of view:

Curl® applets that are not privileged don't have general access to the file system on the client machine. However, unprivileged applets can use persistent data mechanisms to store data on the client machine without the risk of compromising its security.

Curl language persistent data APIs provide an easy-to-use "name/value" mechanism for applets to store and retrieve data in several different formats on the client machine. Security issues aside, an applet could save data in a local file, but it would then have to keep track of the location of the file.

Persistent data also allows the applet writer to store configuration data on the client rather than the server. Accessing data on the server consumes more resources in a more expensive place than storing it on the client. Furthermore, there are scalability problems in storing data on the server as the number of clients increases. Adding more disks, more network bandwidth, or more processing power to a server can be expensive and is sometimes simply impractical.

A Curl applet can also use HTTP cookies to store client side data, but HTTP cookies should generally be used only when they are needed to interact with existing servers or applications.

• HTTP cookies have more restrictive data size limits than the data size limits imposed on Curl persistent data.

• HTTP cookies are more haphazardly shared between applets than Curl persistent data is.

• HTTP cookies are prone to deletion by the web browser.

• HTTP cookies must store all data as strings.

• HTTP cookies are sent back and forth between the server and client, which can represent a security issue if HTTPS/SSL is not being used.

The Curl language persistent data mechanism frees the applet writer from these issues.

From an end user's point of view:

Unprivileged applets are limited in the amount of data they may store, preventing an applet from filling up the local disk.

Unprivileged applets also have access limited to persistent data that they or a related (by URL) applet created. Therefore, they can not interfere with or see unrelated applets' data. The persistent data mechanism is segregated from normal client file system operations. Therefore, these applets cannot gain access to files other than those managed by the persistent data mechanism.

• Use it to store data between invocations of an applet. Examples include saving the high scores for a game applet or saving the recent queries in a database viewing applet, so that they can be reexecuted at a later time.

• Use it to save preferences or configuration information. Often applets can be customized by the user to alter their appearance or functionality. The persistent data mechanism can be used to save and restore the user's preferences.

• Use it to share state between applets. An application may be structured as a number of applets. The persistent data mechanism gives these applets a way to share common state, though it is not a substitute for interprocess communication.

Data in the client persistent data repository is keyed to the Url of the persistent data identifier.

In the default, unshared, case, the persistent data identifier is the Url of the applet, and no other unprivileged applet can access that persistent data.

By making the Url of the persistent data identifier different than the Url of the applet, it can be shared between applets. Do this by creating a file containing only a persistent-data curly expression. (In the default case, the persistent-data curly expression appears in the applet. Here we are putting it into an external file.) Then in each applet use a get-persistent-data-repository call to get the shared repository, and then use get-persistent-data and set-persistent-data, passing them the repository, to access the data.

Create a file that looks like this:

{persistent-data
    "This persistent data is for the Super Excellent
     Curl Applets",
}

In the applets, create a reference to the Repository:

let r:Repository = 
{get-persistent-data-repository pdi-name="name of 
file containing persistent-data curly expression"}

Then use the repository keyword parameter in get-persistent-data and set-persistent-data to reference the Repository:

{set-persistent-data, key, value, repository=r}

Please note that the client-side persistent data mechanism does not currently have the synchronization support that would be required for sharing data between two applets that could be running at the same time, though the mechanism works fine for sharing information between different applets that are executed at different times on the same client machine.

An additional point:

An applet can reference multiple shared persistent data repositories.

For unprivileged HTTP applets, a comparison is made between the URL of the applet and the URL of the persistent data identifier, which is the URL of the file containing the persistent-data call. The URLs must be for the same web server and the URL of the persistent data identifier must be in the same directory as the applet or in an ancestor or descendent directory of the directory containing the applet.

Local file system applets must be privileged to access anything but the default repository associated with the applet.

Privileged applets can access any shared persistent data repository. Or to put it another way, privileged applets can share persistent data with privileged local file system applets and both privileged and unprivileged HTTP Curl® applets.

Here are a few examples:

Case 1:
Url of applet: http://www.mycompany.com/foo/bar/my-applet.curl

Url of persistent data identifier: http://www.mycompany.com/my-persistent-data-identifier.curl

Fine because Url of persistent data identifier is in a parent directory of the Url of the applet.

Case 2:
Url of applet: http://www.mycompany.com/Curl-applets/my-applet.curl

Url of persistent data identifier: http://www.mycompany.com/Curl-applets/persistent-data-identifiers/my-persis tent-data-identifier.curl

Fine because Url of applet is in parent directory of the Url of the persistent data identifier.

Case 3:
Url of applet: http://www.mycompany.com/Curl-applets/my-applet.curl

Url of persistent data identifier: http://www.mycompany.com/Curl-pdis/my-persistent-data-identifier.curl

Security exception because the Url of the applet and the Url of the persistent data identifier aren't in the same directory nor is one in the parent directory of the other.