Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SMILA/Project Concepts/Binary Storage"
< SMILA | Project Concepts
| Line 6: | Line 6: | ||
* The file system will be used as physical storage | * The file system will be used as physical storage | ||
* The [http://commons.apache.org/vfs/ Apache Commons Virtual File System (Commons VFS)] framework is to be used for accessing the file system. | * The [http://commons.apache.org/vfs/ Apache Commons Virtual File System (Commons VFS)] framework is to be used for accessing the file system. | ||
| − | * For performance | + | * For performance improvement (in case of ) the binary storage shall be hierarchically/tree organized; and not flat |
| − | * Binary storage shall | + | * Binary storage shall internally manage its persistence hierarchy |
* The binary service shall be designed as a single bundle / service. Main reason for doing this is that there is only one “client”, the Blackboard service | * The binary service shall be designed as a single bundle / service. Main reason for doing this is that there is only one “client”, the Blackboard service | ||
* Exception handling mechanism should treat all internal binary storage (logical and unexpected) errors and wrap the exceptions into a “binary storage exception” that makes sense for the Blackboard service | * Exception handling mechanism should treat all internal binary storage (logical and unexpected) errors and wrap the exceptions into a “binary storage exception” that makes sense for the Blackboard service | ||
Revision as of 17:19, 7 October 2008
Description
The purpose of Binary Storage is to provide solution for persisting binary objects (content of indexed files) into the file system. The binary objects (files content) shall be simply identified by a unique key / identifier.
Technical aspects for designing the Binary Storage Service
- The file system will be used as physical storage
- The Apache Commons Virtual File System (Commons VFS) framework is to be used for accessing the file system.
- For performance improvement (in case of ) the binary storage shall be hierarchically/tree organized; and not flat
- Binary storage shall internally manage its persistence hierarchy
- The binary service shall be designed as a single bundle / service. Main reason for doing this is that there is only one “client”, the Blackboard service
- Exception handling mechanism should treat all internal binary storage (logical and unexpected) errors and wrap the exceptions into a “binary storage exception” that makes sense for the Blackboard service
- Resources synchronization shall be done at the lowest possible level
- Binary Storage shall manage its configuration internally (highly couple classes are difficult to maintain and hard to understand in isolation – they tend to introduce internal dependencies). Decouple binary storage configuration from blackboard service
- The Binary Storage Service API shall stay as simple as possible
Current Binary Storage Service
Current implementation of Binary Storage is designed in five bundles, where the org.eclipse.eilf.binstorage(.impl) bundle acts as “service factory” for the Blackboard service, providing the files-service, configuration and file-content services.
Current implementation is deprecated and it will be soon changed.