Note: This is currently a verbatim copy of the RequirementsAndGoals wiki page originally hosted at Topaz, and reflects the developers' thinking as of 9/16/08.
Here's a brief summary of what requirements Akubra must fulfill and some of the design decisions made.
Feature | Support | Notes |
|---|---|---|
Embeddable | Yes | This is the primary use case |
Server | As an add-on |
|
Transactional | Yes (JTA) | Some implementations may cheat and not be truly transactional |
Hierarchical | No | App may use hierarchical ids, but Akubra has no notion of or support for containers |
Metadata storage | No (size only) | Blob size is only metadata stored because it's widely supported without requiring extra storage; but it too is optional (though strongly recommended) |
Support app-supplied blob-ids | Yes |
|
Support storage-generated blob-ids | Yes |
|
Allow blobs to be deleted | Yes |
|
Allow blobs to be overwritten | Yes |
|
Allow partial updates of blobs | No |
|
Enumeration of stored blobs | Yes | Necessary for rebuilds |
Pluggable storage back-ends | Yes |
|
Allow local temp storage | Yes | E.g. for caching or temporary bookkeeping |
Allow permanent local storage | No | See http://lists.topazproject.org/pipermail/akubra-dev/2008-August/000074.html |