Spaces/Spi/ProviderSpi

How can Eclipse Spaces Space Providers be extended?

It is possible to extend Eclipse Spaces in the following ways:

• Adding a Space Provider - this is done when there is a need to add a new way of accessing a space
• Adding UI specific for a Space Provider implementation

These are described in more detail below

Space Provider

A Space Provider's main responsibility is to implement the following two interaces in the org.eclipse.spaces.core.provider.spi package:

• ISpaceProvider
• ISpace

The ISpaceProvider's main responsibility is to create an instance of an ISpace given an URI that addresses a space. In order to do this, the implementor of ISpaceProvider must specify a name for the providerScheme to use. The providerScheme is part of the URI, and is used as a key by the core spaces implementation to match a URI with an implementation of ISpaceProvider.

The ISpace main responsibility is to translate the space URI into:

• EFS IFileStore references for (one or both):
  • A flat "files" area (i.e. no nested folders, just a place to store "a list of files"
  • A structured area (i.e. a standard type file system with folders and files)
• A Source Code Repository address (A SVN or CVS URI)

Look at the project "org.eclipse.spaces.localSpaceProvider" which is an implementation of these interfaces. It is almost a generic implementation, but a provider may have special needs and wants to implement the "transaction oriented" begin/end/fail methods to be able to process published files in batch

The main work is to provide an implementation of an Eclipse File System (if one does not already exist). This means implementing the interfaces IFileSystem, IFileStore, IFileInfo and related interfaces.

The plugins

A Space Provider operation plugin is created. This plugin should extend the "org.eclipse.spaces.core" plugin. An example can be found in the project "org.eclipse.spaces.localSpaceProvider".

The space provider plugin extends using the "spaceProviders" extension point, and specifies two things:

• The class that implements ISpaceProvider
• The providerScheme (a string) the class implementing ISpaceProvider is prepared to handle (In the localSpaceProvider example, the providerScheme is called "local".

The space provider plugin should also define an extension point for a "login" mechanism. This is yet to be specified in detail, but should work like this:

• The space provider plugin defines an extension point for getting credentials "credentialsProvider"
• The space provider plugin should obtain the login/password via programmatic means from some keystore (or it is set programmatically via an API - i.e. "setCredentials(String login, String password)" by the user of the service provider implementation.
• If the credentials is not obtainable (not set via API, and they are not in the keyring), then a provided extension of "credentialsProvider" is asked for the credentials.
• If no "credentialsProvider" is available, then the provider gives up with an exception.

This allows a headless packaging where credentials are stated on the command line to be passed to the space provider. The space provider can (subject to user preferences) store credentials in the keyring and reuse them.

When used from a UI, the "credentialsProvider" can popup a window and ask for "login/password" (and ask if user wants to remember them in the keyring).

It is yet to be decided if a generic "credentialsProvider" plugin extension should be created, or if this is up to the provider of a space.

Space Provider UI

The plugin "org.eclipse.spaces.ui" can be extended with an "addSpaceWizardFactory". The implementation should implement IAddWizardFactory in the "org.eclipse.spaces.ui.spi" package. This is trivial to implement. It should return an IWizard instance that allows the user to add a space address to the "org.eclipse.spaces.core.SpaceCatalog". The intent is that this wizard handles:

• user friendly editing of the space address URI
• a way for a user to "sign up"
• branding of the space provider

It is optional to implement the "addSpaceWizardFactory" and the wizard to add a space and instead use the generic wizard for adding a space. The generic wizard does not helpt the user with URI editing, and does not provide a mechanism for "how to sign up"

discussion - we should perhaps break this into two parts; adding a space, and signing up - this way a space provider can reuse the generic part and only implement the signup?