Object Handlers

ExpeDat servers can be configured to access arbitrary storage and automation systems, in addition to regular files.  Server Object Handlers route movedat requests to external scripts and applications, creating a gateway to virtual filesystems, workflows, and object storage.

Object Handlers must be configured on the server and selected by the client.

To access server-side object handlers, obtain a list of available handler action codes from the server administrator.  Each code corresponds to a program which will be run on the server to either process data or perform a function.  Handlers may be used with Send transactions to send data to the handler, or with a Get transaction to generate data for download or perform other tasks.  Handlers may also be used with file maintenance and folder listing functions.

Using Object Handlers

To activate an object handler append an equal-sign and the handler action code to end of the server or host group string.  For example, to download data from handler xyz:

movedat user@example.com=xyz:handler/input localfile

Note that the path portion of the target, "handler/input" in this case, might not be a pathname.  This string will be passed directly to the handler and the handler may interpret it as any arbitrary data.  To display the output instead of saving it to a file, use the -D option and do not specify a local target:

movedat -D user@example.com=xyz:handler/input

You can also send data to a handler, either from a file or a pipe.  The servedat chapter shows an example of a handler which sends email notifications.  It expects the client to upload the body of an email and the path to be the address of the recipient:

echo "This is a message for Joe" | movedat user@example.com=Notice:joe

Refer to the server's Object Handler chapter for complete details on what a handler can do.

Earlier versions of movedat required a -o option and put the handler at the end of the path.  That syntax is now deprecated and may be removed in the future.

Common Syntax

Following are examples of basic movedat functionality using object handler syntax.  These examples assume a handler that works with file-like objects.

Send (Upload):

movedat local.dat user@example.com=xyz:remote.dat

Get (Download):

movedat user@example.com=xyz:remote.dat local.dat

Rename:

movedat -m user@example.com=xyz:remote.dat newremote.dat

Delete:

movedat -x user@example.com=xyz:newremote.dat

List:

movedat user@example.com=xyz: movedat user@example.com=xyz:folder/

Get with Active-Passive Failover:

movedat 'user@svr1.example.com;svr2.example.com=xyz:remote.dat' local.dat

A handler may not support all of the above action types.  If it does not recognize a request, a handler should return an error such as "Unsupported Feature", but this is up to the author of the handler.

Secondary Actions

In addition to the path string, movedat can supply a secondary action code to the handler.  This is a string which follows the object action code and is passed to the handler as part of its SV_ACTION environment variable.  For example, to run handler xyz with secondary action code abc:

movedat -D user@example.com=xyz,abc:handler/input

The file maintenance commands shown above use this same mechanism.  The following commands are equivalent:

movedat -x user@example.com=xyz:newremote.dat movedat 'user@example.com=xyz,*dl:newremote.dat'

By combining custom path strings with secondary actions, you can use movedat and object handlers to supply sophisticated command instructions to server-side utilities.

Limitations

When using an object handler, the following limitations apply:

• Inline compression is not available.
• Streaming Folders is not available.
• Downloading a folder with -h requires that the handler generate a recursive structured list in response to a '*lr' secondary action.
• If an object handler transaction is interrupted, it cannot be resumed.  Automatic Retry will start over from the beginning.
• Progress and speed information may be inaccurate.
• Performance will be limited by the ability of the handler to process data.
• After data is uploaded, a Send transaction will wait until the handler signals that it has finished processing the data.  This may result in a long delay after the upload of data across the network has completed.
• The object handler is responsible for reporting errors.  movedat will attempt to translate these into its own exit codes.

Individual object handlers may have additional limitations, depending on their implementation.