Collaboration diagram for Plugins:
![]() |
A plugin is a way to implement application-independent reliability and performance tuning behavior. Plugins are written using the API described in this document.
A plugin is created by defining a globus_ftp_client_plugin_t which contains the function pointers and plugin-specific data needed for the plugin's operation. It is recommended that a plugin define a a globus_module_descriptor_t and plugin initialization functions, to ensure that the plugin is properly initialized.
The functions pointed to in a plugin are called when significant events in the life of an FTP Client operation occur. Note that plugins will only be called when the plugin has the function pointer for both the operation (get, put, list, etc), and the event (connect, authenticate, command, etc), are defined. The command and response functions are filtered based on the command_mask defined in the plugin structure.
Every plugin must define copy and destroy functions. The copy function is called when the plugin is added to an attribute set or a handle is initialized with an attribute set containing the plugin. The destroy function is called when the handle or attribute set is destroyed.
|
FTP Client plugin An FTP Client plugin is used to add restart, monitoring, and performance tuning operations to the FTP Client library, without modifying the base API. Multiple plugins may be associated with a globus_ftp_client_handle_t.
|
|
Plugin copy function. This function is used to create a new copy or reference count a plugin. This function is called by the FTP Client library when a plugin is added to a handle attribute set, or when a handle is initialized with an attribute which contains the plugin. A plugin may not call any of the plugin API functions from it's instantiate method.
|
|
Plugin destroy function. This function is used to free or unreference a copy of a plugin which was allocated by calling the instantiate function from the plugin.
|
|
Plugin connection begin function. This callback is used to notify a plugin that connection establishment is being done for this client handle. This notification can occur when a new request is made or when a restart is done by a plugin. If a response_callback is defined by a plugin, then that will be once the connection establishment has completed (successfully or unsuccessfully).
|
|
Plugin authentication notification callback. This callback is used to notify a plugin that an authentication handshake is being done for this client handle. This notification can occur when a new request is made or when a hard restart is done by a plugin. If a response_callback is defined by a plugin, then that will be once the authentication has completed (successfully or unsuccessfully).
|
|
Plugin chmod notification callback. This callback is used to notify a plugin that a chmod is being requested on a client handle. This notification happens both when the user requests a chmod, and when a plugin restarts the currently active chmod request. If this function is not defined by the plugin, then no plugin callbacks associated with the chmod will be called.
|
|
Plugin chmod notification callback. This callback is used to notify a plugin that a chmod is being requested on a client handle. This notification happens both when the user requests a chmod, and when a plugin restarts the currently active chmod request. If this function is not defined by the plugin, then no plugin callbacks associated with the chmod will be called.
|
|
Plugin delete notification callback. This callback is used to notify a plugin that a delete is being requested on a client handle. This notification happens both when the user requests a delete, and when a plugin restarts the currently active delete request. If this function is not defined by the plugin, then no plugin callbacks associated with the delete will be called.
|
|
Plugin feat notification callback. This callback is used to notify a plugin that a feat is being requested on a client handle. This notification happens both when the user requests a feat, and when a plugin restarts the currently active feat request. If this function is not defined by the plugin, then no plugin callbacks associated with the feat will be called.
|
|
Plugin mkdir notification callback. This callback is used to notify a plugin that a mkdir is being requested on a client handle. This notification happens both when the user requests a mkdir, and when a plugin restarts the currently active mkdir request. If this function is not defined by the plugin, then no plugin callbacks associated with the mkdir will be called.
|
|
Plugin rmdir notification callback. This callback is used to notify a plugin that a rmdir is being requested on a client handle. This notification happens both when the user requests a rmdir, and when a plugin restarts the currently active rmdir request. If this function is not defined by the plugin, then no plugin callbacks associated with the rmdir will be called.
|
|
Plugin list notification callback. This callback is used to notify a plugin that a list is being requested on a client handle. This notification happens both when the user requests a list, and when a plugin restarts the currently active list request. If this function is not defined by the plugin, then no plugin callbacks associated with the list will be called.
|
|
Plugin verbose list notification callback. This callback is used to notify a plugin that a list is being requested on a client handle. This notification happens both when the user requests a list, and when a plugin restarts the currently active list request. If this function is not defined by the plugin, then no plugin callbacks associated with the list will be called.
|
|
Plugin machine list notification callback. This callback is used to notify a plugin that a list is being requested on a client handle. This notification happens both when the user requests a list, and when a plugin restarts the currently active list request. If this function is not defined by the plugin, then no plugin callbacks associated with the list will be called.
|
|
Plugin mlst notification callback. This callback is used to notify a plugin that a mlst is being requested on a client handle. This notification happens both when the user requests a list, and when a plugin restarts the currently active list request. If this function is not defined by the plugin, then no plugin callbacks associated with the list will be called.
|
|
Plugin stat notification callback. This callback is used to notify a plugin that a stat is being requested on a client handle. This notification happens both when the user requests a list, and when a plugin restarts the currently active list request. If this function is not defined by the plugin, then no plugin callbacks associated with the list will be called.
|
|
Plugin move notification callback. This callback is used to notify a plugin that a move is being requested on a client handle. This notification happens both when the user requests a move, and when a plugin restarts the currently active move request. If this function is not defined by the plugin, then no plugin callbacks associated with the move will be called.
|
|
Plugin get notification callback. This callback is used to notify a plugin that a get is being requested on a client handle. This notification happens both when the user requests a get, and when a plugin restarts the currently active get request. If this function is not defined by the plugin, then no plugin callbacks associated with the get will be called.
|
|
Plugin put notification callback. This callback is used to notify a plugin that a put is being requested on a client handle. This notification happens both when the user requests a put, and when a plugin restarts the currently active put request. If this function is not defined by the plugin, then no plugin callbacks associated with the put will be called.
|
|
Plugin third-party transfer notification callback. This callback is used to notify a plugin that a transfer is being requested on a client handle. This notification happens both when the user requests a transfer, and when a plugin restarts the currently active transfer request. If this function is not defined by the plugin, then no plugin callbacks associated with the third-party transfer will be called.
|
|
Plugin modification time notification callback. This callback is used to notify a plugin that a modification time check is being requested on a client handle. This notification happens both when the user requests the modification time of a file, and when a plugin restarts the currently active request. If this function is not defined by the plugin, then no plugin callbacks associated with the modification time request will be called.
|
|
Plugin size notification callback. This callback is used to notify a plugin that a size check is being requested on a client handle. This notification happens both when the user requests the size of a file, and when a plugin restarts the currently active request. If this function is not defined by the plugin, then no plugin callbacks associated with the size request will be called.
|
|
Plugin abort notification callback. This callback is used to notify a plugin that an abort is being requested on a client handle. This notification happens both when the user aborts a request and when a plugin aborts the currently active request.
|
|
Plugin read registration callback. This callback is used to notify a plugin that the client API has registered a buffer with the FTP control API for reading when processing a get.
|
|
Plugin write registration callback. This callback is used to notify a plugin that the client API has registered a buffer with the FTP control API for writing when processing a put.
|
|
Plugin data callback handler. This callback is used to notify a plugin that a read or write operation previously registered has completed. The buffer pointer will match that of a previous plugin read or write registration callback.
|
|
Command callback. This callback is used to notify a plugin that a FTP control command is being sent. The client library will only call this function for response callbacks associated with a command which is in the plugin's command mask, and associated with one of the other ftp operations with a defined callback in the plugin.
|
|
Response callback. This callback is used to notify a plugin that a FTP control response has occurred on a control connection. FTP response callbacks will come back to the user in the order which the commands were executed. The client library will only call this function for response callbacks associated with a command which is in the plugin's command mask, or associated with one of the other ftp operations with a defined callback in the plugin.
|
|
Fault notification callback. This callback is used to notify a plugin that a fault occurred while processing the request. The fault may be internally generated, or come from a call to another library.
|
|
Completion notification callback. This callback is used to notify a plugin that an operation previously begun has completed. The plugin may not call any other plugin operation on this handle after this has occurred. This is the final callback for the plugin while processing the operation. The plugin may free any internal state associated with the operation at this point.
|
|
|
Restart an existing list. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in list events will receive a list callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing verbose list. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in list events will receive a list callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing machine list. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in list events will receive a list callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing MLST. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in list events will receive a list callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing STAT. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in list events will receive a list callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing chmod. This function will cause the currently executing chmod operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in chmod events will receive a chmod callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing cksm. This function will cause the currently executing cksm operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in cksm events will receive a cksm callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing delete. This function will cause the currently executing delete operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in delete events will receive a delete callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing feat. This function will cause the currently executing feat operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in feat events will receive a feat callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing mkdir. This function will cause the currently executing operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in mkdir events will receive a mkdir callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing rmdir. This function will cause the currently executing operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in rmdir events will receive a rmdir callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing move. This function will cause the currently executing move operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially new URLs and attributes. The user will not receive any notification that a restart has happened. Each plugin which is interested in get events will receive a move callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing get. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued will be cleared and reused once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in get events will receive a get callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing put. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. Any data buffers which are currently queued but not called back will be resent once the connection is re-established. The user will not receive any notification that a restart has happened. Each plugin which is interested in get events will receive a put callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart an existing third-party transfer. This function will cause the currently executing transfer operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URLs and attributes. The user will not receive any notification that a restart has happened. Each plugin which is interested in third-party transfer events will receive a transfer callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart a size check operation. This function will cause the currently executing size check operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. The user will not receive any notification that a restart has happened. Each plugin which is interested in size operations will receive a size callback with the restart boolean set to GLOBUS_TRUE.
|
|
Restart a modification time check operation. This function will cause the currently executing modification time check operation to be restarted. When a restart happens, the operation will be silently aborted, and then restarted with potentially a new URL and attributes. The user will not receive any notification that a restart has happened. Each plugin which is interested in modification time operations will receive a modification time callback with the restart boolean set to GLOBUS_TRUE.
|
|
Get restart marker This function will allow this user to get the restart marker associated with a restarted file transfer. This function may only be called within the get, put, or third party transfer callback in which the 'restart' argument is GLOBUS_TRUE
|
|
Abort a transfer operation. This function will cause the currently executing transfer operation to be aborted. When this happens, all plugins will be notified by their abort callbacks. Once those are processed, the complete callback will be called for all plugins, and then for the user's callback. The complete callback will indicate that the transfer did not complete successfully.
|
|
Add data channels to an existing put transfer. This function will cause the currently executing transfer operation to have additional data channels acquired if the attribute set allows it.
|
|
Remove data channels from an existing put transfer. This function will cause the currently executing transfer operation to have data channels removed, if the attribute set allows it.
|
about globus |
globus toolkit |
dev.globus
Comments? webmaster@globus.org