BRIDGE object version histories

• Versions are difficult to address, since the URL for a specific version changes each time a new version is created. Among other problems, this makes version annotation difficult. Possible solutions include:
  1. Reverse numbering so that the index in the version list does not change. This is probably the easiest solution, but causes problems if we allow individual versions to be purged from the history.
  2. Use a timestamp (YYYYMMDDhhmmss) to identify the version. This will produce less attractive URLs, but solves the problem of versions being removed. It also simplifies queries of the form "all versions from a given day" or "closest version to a given time"
• Versions are stored in a linked list. This was an attempt to provide for scalability, but in practice we almost always pull down meta-data for the entire version history of an object. This leads to lots of small server requests, and adds significantly to database clutter -- at last check, the ReplicationRecord objects used to store per-version meta data made up about half the total number of objects in the DB. possible solutions include:
  1. Switch to SQL for storage of meta-data. This is probably the most scalable approach, but violates the general philosophy of staying self-contained and, in particular, would complicate garbage collection improvements that will have to be made in the near future.
  2. Switch to a list (probably a subclass of ObjectRecordList) to store EmbeddedObjectDescriptors for each version a reference to the list could be stored as an attribute in the descriptor for the live object, and the list could contain a pointer back to the object it is a history for.
• Semantics of version history management when an object is copied are not clearly defined
• The ObjectRelation design on which the history mechanism is based may be needlessly complex [?]
• Version histories cannot be cleared or otherwise modified
• The UI provides no simple way to revert to an older version of an object

1. Create an ObjectRecordList subclass for version lists (ReplicatedRelationList?)
2. Update/replace ReplicatedRelation to use list object rather than linked list
3. Create utility to replace ReplicatedRelations with relation lists
4. Update (or replace?) VersionServlet to be more general: Given a relation name and an index or element name, retrieve the relation and render the element