Infrastructure

Currently morpho use the identifier itself to keep track its history. For example. foo.300.2 is a newer version of foo.300.1.

The new morpho will change the policy. Instead, we should look up the system metadata associated with an object to find out its history or newer version.

System metadata has two elements named obsoletes/obsoletedBy

Here is an example:
System metadata for object 100 is: 200
System metadata for object 200 is: 300
System metadata for object 300 doesn't have the "obsoletes" element.

The newest version is object 100, the oldest version is 300. 200 is the middle.

Morpho has two situations needing to know the version history.
1. Building the query result set. The query result set only shows the newest version. For the network search, it is easy since we only get the newest version. But the local search will return every document matching the query. So we needs to trim the old version documents. Also, we need to compare the versions of the network copy and local copy. If they are same, the document's location status will show both. If the network copy has newer version, the location status will show network. If the local copy has newer version, the location status will show local.

1. Menu item for "Open the old version".

We may have two options to keep track the revisions:
1. When we needs the information, we search the system metadata folder to get it. I can imagine the response time will be long.
2. When morpho starts up, morpho will go through the metadata folder to collect the revision information and keep them in an object(i.g., a list of list). When we needs the information, just call the object directly. The response time will be short. However, the morpho start-up time may be long if the user has a big local data set. The solution maybe is to cache the object to a csv file. So only the first time to start morpho will take a long time.