Revision as of 06:25, 21 December 2007

Spaces Architecture

At the highest abstraction level, the architecture consists of:

1. Applications (user interface, automation "headless builds" etc.)
2. API (the core spaces functionality)
3. SPI (Service Programming Interface)
4. Implementation for different service provider technologies

Applications

Examples:

• View into spaces added to a workspace
• Wizards - managing spaces in workspace
• Space properties view - services provided by space provider, etc.
• Signing up for an account at a service provider

It is important that headless mode is considered when structuring application plugins.

API

Spaces Service Providers

Each provider of spaces creates a plugin for a "Spaces Service Provider" extension point. When a user wants to add a Space Resource to a project, the first selection is among the available providers (e.g. AOL-X-Drive, SourceForge, SpaceSVN, SpacesCVS).

Common traits are:

• Name, the name of the service provider
• A description of the service
• Icon for display with the description (e.g. a space provider logo)
• A URL to read more about the provided service
• Small Icon for use in association with a Space Resource
• An enumeration of available Space Services
• A list of Account information
  The idea being that some service providers allows users to have multiple accounts.

Space Service

A Space Service describes a service available for spaces from a Spaces Service Provider

Management Services

Management services are about creation/maintenance of Accounts, and Spaces Resources associated with such an Account.

• Account Reference
  Mandatory. Adding/Modifying an account by passing account information. Different providers may have implementation specific ways of storing the account information (e.g. Eclipse key ring, some (hopefully encrypted) file in the local file system, etc.). The idea is that the spaces project should reuse these implementations and not use a separate "vault"/"key ring". Produces information that can be stored in spaces project meta data.
• Account creation / Sign up
  Optional. A full implementation allows an account to be created via the API, but a simple implementation may consist of just information and a URL to a website where a user can sign up. A full implementation should add the new account to the set of accounts (i.e. create an account reference).
• Space Reference
  Mandatory. Adding/Modifying a reference to a space for an Account. Produces information that can be stored in spaces project meta data.
• Space Creation
  Optional. A full implementation allows creating a space and adding it to the set of references spaces.
• Future - Additional management services:
  • Delete of space
  • Controlling access rights to space
  • Change password
  • More ?

Content? Services

Content services are about what you can do with the content in a space.

• Versioned Storage
  • CVS
    Optional. This service provides the hookup between a Space Resource and the Team/CVS implementation in CVS. Different Spaces Service Providers may have different ways of addressing the CVS. Once the connection has been made, the user uses the normal Team /CVS plugin to do operations on the CVS instances.
  • SVN
    Optional. Same as CVS, but for SVN. Needs to be discussed - there is no standard SVN plugin yet, is there?
• Spaces Remote File System
  Optional. An unversioned API defined by spaces for reading and writing files and folders. (Assumed to be modeled after the AOL X-Drive API). This API should be generic enough to allow implementations for technologies like ftp, webdav, or indeed a local file system.
• HTTP access
  Optional. Allows access to the content via regular "read only" URLs.
• HTTPS access
  ?

Collaboration Services

From the proposal:

The key objective here is that the spaces project provides the mechanisms for hookup between the Space Resource and Collaborations provided via different Collaboration Technologies.

Bullets below is a collection of thoughts for discussion.
This area is somewhat complicated, as different Spaces Service Providers provide these services in different ways:

• A provider like source forge, where "a project" would be synonym to a "space" provides collaboration services associated with the actual space. These services are provisioned when the space (i.e. "project") is created. Some such services may always be created, and others may be created "on demand".
• Some other Space Service Provider may offer collaboration as an additional service, and such a service may be used to collaborate in a wider scope - an example perhaps being the Eclipse wiki that will be used as a collaboration tool for several eclipse spaces, or a space being associated with a particular project in a Bugzilla, as opposed to an individual Bugzilla per space/project.
• Some providers offer collaborative tools for a service fee (e.g. on-line video conferencing)
• All collaborations typically used by a group collaborating "in a space" are not provided by a single service provider, and also typically not by the same provider as the basic "space".
• A question is how "documentation" should be viewed. One aspect of documentation is that it is a thing a group is collaborating to produce - the same way as the code is produced. Another aspect is if the intended audience - is this the "end user documentation", or "documentation for the developers".
• The spaces project in itself is a collaboration technology! Assuming that a user A wants to collaborate with user B, how is the setup for user A propagated to user B? Should A send B and email with all the references B should install in order to access the required spaces? Or can user B start with a "basic Eclipse" ?
• What if the wanted Collaboration also requires additional plugins? Say, a Mylyn adapter to some issue tracker?
• Several of the above questions makes it more natural to think of a Collaboration as a component (i.e. a Buckminster component/cspec) comparable to other resources such as source, "technology plugins" such as compilers, etc., as this would allow creation of distros, dependencies between components etc.

• At the most basic level, some description of a Collaboration is needed. This should define:
  • Name - to allow identification
  • Reference to Collaboration Technology - so it is possible to connect to it
  • A description - if the name is not enough to understand the purpose of the Collaboration
• A simplistic API is to let the Space Resource provide an list of Collaborations.
• A slightly more advanced API allows definition/Addition of Collaborations to a space - i.e. Adding references to existing places of collaboration.
• A more advanced API defines provisioning of a Collaboration (e.g. creating a wiki, or a bugzilla instance/project)

• So - basic questions - how are collaborations defined? Should a service provider return a list of some Buckminster artifacts (XML) that buckminster can operate on directly, or should it provide some spaces specific information that can be transformed into buckminster artifacts the same way buckminster translates other types of meta data "on the fly"? An approach using a specific definition seems cleaner as the provider is then not exposed to the full complexity of buckminster, but on the other hand, such flexibility is perhaps needed in some cases.

Proposals? Ideas?

Spaces Catalog

The spaces catalog is comparable to the list of repositories available for Team/CVS and SVN. Access to spaces is a cross cutting concern, the same settings apply to multiple projects, and may be required before projects are available (since a project can be checked out from a space). The data in this catalog is also comparable to Team Project Set.

• The catalog itself is part of the workspace meta data
• The API consists of CRUD operations of Space Resources in the catalog
• When adding a space, the user runs a wizard where a list of Spaces Service Providers are listed, the user selects the provider, and then if a new space should be created (if provided by the Spaces Service Provider), or if they want to use an existing space, properties are then edited as needed).
• When sharing of Space Resources is wanted, they are added to a template workspace that later is used when doing headless builds etc. (This is important as credentials are needed for secure access to both spaces, and services provided by the space provider but accessed via 'non spaces' common APIs - e.g CVS or SVN access).

Space Resource

A Space Resource is the data that makes it possible to connect to a space using a Space Provider. All Space resources share a common set of traits:

• A name that identifies this space instance from others in the user interface - used when selecting a space when publishing etc.
• A URI used to connect to the space
• Credentials to access the space
• An enumeration of available Space Services