In production there currently exists both a tape storage and a disk storage implementing the SB Pillar code-base.

SB Pillar limitations

The following discribes limitations of the SB Pillar implementation.

Allowed Checksum Types

Request of all checksum only allowed for the default checksumtypes.

As the calculation of checksum is a resource-consuming task, the SB pillars will only allow requests for checksums of the default type as these are cached. Requests for non-default checksums will be rejected with a REQUEST_NOT_SUPPORTED response. If non-default checksums are requesred, these need to be requested one by one.

The default checksum types supported are MD5 and SHA1. Both of these types has the option to include an optional salt value. If a salt is included it will force the calculation to use HMAC and the specified algorithm.

Additional checksum types should be easily supported, thus can be implemented if the default checksum type is changed. Though this change will require back-end support in the Python code prior to enabling support in the Java code. 

Upload of results unsupported

Returning the results for getFileIDs, getChecksums and getAuditTrails to a file-exchange ULR is not supported.

Allowed character and length of FileID

The limitations to fileID's both affects the length and the allowed characters.

The maximum length is 250, and is limited by the file system - as it allows for a maximum of 255 characters. The 5 character difference is due to the fact that the last 5 available characters is reserved for use in the back-end.

The Java code communicates with the back-end using a bash shell. This means that the input has to be limited to avoid a malformed fileID executing something illegal on the command line. When using such an approach, it is reasonable to have a limitation on which characters are allowed in the fileID.

Currently the allowed values are best described by the following regex: [a-zA-Z_.0-9]
Characters for consideration is  '-' and '%' as they have viable use cases.