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 |