The PDS Module provides an implement of two resource identifier schemes pds: and fpds: They provide a mechanism for persistent storage of representations.

Zones

PDS persists representations into zones, this allows pds:/ space to be disambiguated for different applications within the same host. Providing a globally unique zone identifier for your application therefore allows it to maintain a separate persistence address spaces without fear of overlap with other applications.

To determine which zone is being used the pds:/ accessor SOURCEs the resource:

res:/etc/pdsConfig.xml

which in XML looks like...

If no pdsConfig.xml is resolved a default zone is used.

Implementation Engine

Internally the pds:/ accessor is a thin front-end - it determines the NetKernel instance name, the zone and the pds:/ identifier - it then makes a sub-request to an active:pds implementation engine which must provide the physicall level persistence mechanism.

An engine must have the following interface grammar:

The implementation service must support the 4 verbs and must store data unambiguously based upon the 3 argument identifiers.

Persistence engines are pluggable and are simple to create if you wish to leverage your own storage infrastructure. There is one implementation provided with the pds module.

Database Backed Persistence

An H2 database-backed persistence engine is provided from the secondary space :

urn:org:netkernel:mod:pds:rdbms:local

To use this implementation you would import both of these spaces...

You would then have pds:/ implemented against an H2 database store. This implementation is persistent between system restarts.