The IPIPersist infrastructure is designed to get back your object in the fastest and most consistent way. If every program decided on its own how to persist and restore objects, then in some cases, two programs could get two different objects back from the same persisted information.
Here are two examples.
The persistence string for a PIPoint stores four things:
When restoring the PIPoint, it first tries to find the server by ID and then by name. Once it has found the server, it tries to find the PIPoint by ID and if that fails, by name.
The reason for this is that the Server name and PIPoint name could change, but the ID's won't.
It is possible to pass a context variable to the IPIPersist interface to tell it to prefer the name to the ID.
In the PI-SDK, there is no way to ask for a PIModule directly from the server by passing its UniqueID. To persist a PIModule yourself, you would have to store the path of the PIModule from a root module down to the module in question. It would be very slow to have to retrieve each module in the path and its children.
The other problem is that if the name of any of the PIModule's in the path has changed since you saved the path, you wouldn't be able to find the persisted PIModule.
Or worse, you would find a different module if the original module was moved to another path and a new one with the same name was put in its place.
The IPIPersist infrastructure avoids these problems by retrieving the PIModule directly from the server by the UniqueID, which never changes.
Objects that don't have a unique identifier (PIProperty and PIAlias) have to use the object name in the persistence string. In the case of PIProperty's, the persistence string includes the names of all the properties above it in the hierarchy.
If any of these names change, the persistence string will no longer be valid.