Notice: This Wiki is now read only and edits are no longer 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 10: | Line 10: | ||
== Technical aspects for redesigning the Binary Storage Service == | == Technical aspects for redesigning the Binary Storage 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 |
* Resources synchronization shall be done at the lowest possible level | * Resources synchronization shall be done at the lowest possible level | ||
* Binary Storage shall manage its configuration internaly (dighly 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 | * Binary Storage shall manage its configuration internaly (dighly 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 | ||
Revision as of 15:27, 7 October 2008
Description
The purpose of Binary Storage is to provide solution for persisting (file system) the content of indexed files into the file system. The files shall be simply identified by a unique key / identifier. The Apache Commons Virtual File System (Commons VFS) framework is to be used for accessing the file system.
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 serices.
Technical aspects for redesigning the Binary Storage 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
- Resources synchronization shall be done at the lowest possible level
- Binary Storage shall manage its configuration internaly (dighly 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
