Support for multiple collections in the same bitrepository installation
This is a major release which changes the previous paradigm of one collection pr. bitrepository to allow many collections in the same bitrepository. This means that where the CollectionID was previously always the same throughout a installation, and were therefore mostly implied, a CollectionID is now necessary to access most of the functionality in the system.
The set of collections are defined in the RepositorySettings (formerly CollectionSettings), where each collection has a list of pillars defined.
New web gui for the reference services
The previous web GUI was evolved from the initial test GUI, and as for some while needed a redesign. As the focus on the web GUI has been increasing during the last periode, the GUI for the services have been reimplemented. This means:
The old GUI has been removed.
Access to the different protokol operations should now be done through the command line client. These operations are no longer available the the web gui.
The new GUI is based on twitter bootstrap.
Detailed information access has been added to many of the information elements on the GUI. This means it is possible to click on GUI elements to show the next level of details for this information.
The information on the integrity GUI has been greatly increase.
The performance of the integrity checking has been improved.
The new GUI has support for multiple collection.
The different services are now access through individual url's. This makes it easy to link directly to a service GUI.
New commandline client
A untested version of the client was available in the 0.23 release. The 0.24 command line client has been improved with
Improved argument validation
Better output for the getfileids and getchecksums commands
A list of know bugs has also been created for the cmd client, see the 'Uncovered bugs' listing below to view the complete list.
The FileDir settings in the PillarSettings have been replaced by a CollectionDirs defining the directories to map the files stored for the collections. Each CollectionDirs maps a list of collectionID which should be mapped to a set of dirs. If no collectionIDs are defined in a CollectionDirs element, the dir file be used as the default dir.
Example (where one collection has explicitly defined file-dirs and all other collections use the default file-archive dir):