Bug #163

need data repository interface for metacat

Added by Matt Jones over 18 years ago. Updated over 11 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 systemResolved04/09/2001

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


#1 Updated by Matt Jones over 18 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).

#2 Updated by Matt Jones about 18 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.

#3 Updated by Matt Jones over 17 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.

#4 Updated by David Blankman over 16 years ago

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

#5 Updated by Jing Tao over 11 years ago

I don't think we need this feature anymore.

#6 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 163

Also available in: Atom PDF