Activity intermediate-level API
- How we pass around the data in files?
- checkout/checkin model
- activities want to directly work with removable devices (security?)
- update objects without creating a new version
- data types in the metadata (properties in namespaces?) (Trac #2430)
- special properties that the DS need to know about
- versions use a composite key?
- express hierarchy (just one level?) object spaces?
- query available space
- how can we assure atomicity in multi-document updates?
- we may need to have the same object referenced from several entries. For example, we could have an entry "Interviewed my aunt" and another "Listened to 'Interview to my aunt'". Both should refer to the same version of the same object.
- how can we give feedback about the progress of DS operations? We'll need it if any copy happens inside the DS. (Trac #2761)
- need a way to efficiently query the number of entries that one query matches. (Trac #2454)
- allow activities to provide extensions for extracting fulltext content from arbitrary files. (Trac #2460)
- allow incremental saving, that is, "streaming" into the file held by a journal entry without having to create a potentially big temp file first. (bertf)
- Diff-based storage to minimize disk use when storing many versions? Ben 13:08, 21 January 2008 (EST)
- How do you store a diff if the entry is a .tar.gz of many files?
- Some activities will produce entries that are not amenable to generalized diff algorithms, but can be stored efficiently by domain-specific diff algorithms (e.g. Paint and png files). How can Activities register to handle their own differential compression, or how will type-specific diff be implemented?
- Can a gitattributes(5)-like design help here?
- how can we assure maximum compatibility between format changes in the db? (Trac #2627)
- Test suite?
- what should happen when the db gets corrupted? (Trac #3180)
- need to make sure that we don't store too many files in one single directory (Trac #4411)