E-mail
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 |
