DatastoreOpenIssues: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 11: | Line 11: | ||
* query available space |
* query available space |
||
* how can we assure atomicity in multi-document updates? |
* how can we assure atomicity in multi-document updates? |
||
== DatastoreInternals == |
|||
* Diff-based storage to minimize disk use when storing many versions? [[User:24.91.135.58|24.91.135.58]] 13:07, 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? |
|||
== Journal == |
== Journal == |
Revision as of 18:07, 21 January 2008
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?)
- 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?
DatastoreInternals
- Diff-based storage to minimize disk use when storing many versions? 24.91.135.58 13:07, 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?
Journal
- Need support from the DS to implement date scrolling?