Bug #1217
closedExtend Metacat Interface and Client
0%
Description
The Metacat interface, implemented by the MetacatClient class,
exposes a number of core actions of the MetacatServlet as HTTP
requests to the servlet. The current list of supported actions
includes:
login
logout
read
squery
insert
update
delete
A number of additional actions, most of which are not
critical but are convenient, are not supported by the interface:
query
export
readinlinedata
validate
setaccess
getaccesscontrol
getprincipals
getdoctypes
getdtdschema
getdataguide
getlastdocid
getrevisionanddoctype
(Note: some of the methods listed above are obsolete and
therefore should not be included in the extended interface.
The complete list of methods that should be added to the
interface is yet to be determined.)
Some of the methods in the extended set are useful to other
clients, such as Harvester. However, Harvester should interact
exclusively with the MetacatClient, rather than directly with the
Metacat servlet. Therefore, the current interface should be
extended with the additional convenience methods so that they
can be used by Harvester and potentially other clients.
There are two ways that the current interface could be extended:
(1) Add a new interface, 'MetacatExtendedInterface.java', to
hold the definitions for the convenience methods. The MetacatClient
class would implement both the current Metacat interface and the
MetacatExtendedInterface. The advantage of this approach is that
the current Metacat interface can be kept simple in that it will
only define the core methods.
(2) Add the new methods to the existing Metacat interface.
The advantage of just adding these methods to Metacat.java is
programmatically it's easier because you only have to cast to one
interface (not two) to make method calls.
We will determine in the next few days which of these two
approaches to use.
A secondary goal of this task is to improve the documentation for
the methods in the extended interface.
A future goal (outside the scope of this task) is to refactor
Morpho and other code to use the MetacatClient to interact with
MetacatServlet.
Updated by Matt Jones almost 17 years ago
Moving this up in priority, so that we can get around the problem of having all data one one logical volume. Should support a configurable list of filesystem directories for storage.
Updated by ben leinfelder over 11 years ago
- Status changed from New to Closed
Much if not all of this has been in the MetacatClient for a long time now. Since we are deprecating the Metacat API in favor of the DataONE API, I am going to close this because any critical repository features should be addressed in that more general API.