Bug #163


need data repository interface for metacat

Added by Matt Jones over 23 years ago. Updated almost 16 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Recent discussions have indicated that the metacat server should shield client
interaction from the SRB and other data storage systems (e.g., http servers).
Consequently, we need a new architecture for passing data to, and getting data
from, the metacat server. The metacat server would then look at the address for
the data object and dynamically load an adapter class that handles communication
with the appropriate backend data system (e.g., SRB, http). This could be
implemented as protocol handlers, or otherwise. The SRB adapter will require
extensions to the current srb RMI server to allow for streaming data objects.
All adapters will need to make use of the authentication and access control
interfaces, so there may be a need to extend those interfaces. At a minimum the
SRB adapter will need to query the authentication interface to find out the
proper MCAT username and password to use (which might differ from the original
if there is a user proxy system set up).

This proposed architecture assumes that the bottleneck introduced by passing all
data through a few servers is negligible. the alternative is to connect clients
directly to the SRB RMI server, which opens up possibilities of new clients
causing metadata/data synchronization problems.

Related issues

Blocked by Metacat - Bug #194: manage files by accession# on file systemResolvedMatt Jones04/09/2001

Blocked by Metacat - Bug #195: allow metacat to store files on multiple fsIn ProgressJing Tao04/09/2001

Actions #1

Updated by Matt Jones about 23 years ago

Chad and Dan's initial implementation of this interface allows users to store
data on the Morpho server file system by opening a custom socket to the server.
We now need to generalize the backend interface to this system to allow Metacat
admins to configure the repositories used, either the local file store or the
SRB system, or others as developed. Consequently, we need to re-evaluate the
interface to generic repositories that we are using in the
and classes. Owne has agreed to take on this task,
and implement the SRB interface, and rewrite Metacat so that multiple
repositories can be running at one time (and are dynamically loaded as needed).

Actions #2

Updated by Matt Jones almost 23 years ago

At the Santa Barbara meeting we agreed to create a generic RepositoryInterface
class that defines the set of methods used to access any backend data storage
system, and then implement a single adapter class (FSAdapter) that allows
stroage of objects on the file system. We have decided to hold off on the
SRBAdapter for now.

Actions #3

Updated by Matt Jones about 22 years ago

Postponing until a later release. SRB functionality is a useful addition but not
critical at this point. It would still be nice to have this modularity built in,
but isn't critical at this point.

Actions #4

Updated by David Blankman about 21 years ago

In the process of hiring students to help work on this product

Actions #5

Updated by Jing Tao almost 16 years ago

I don't think we need this feature anymore.

Actions #6

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 163


Also available in: Atom PDF