Revision as of 09:45, 28 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 a reference to an account by passing account information. Different providers may have implementation specific ways of storing the account information (e.g. Eclipse key ring, some (probably 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 Account Reference information that can be stored in spaces project meta data that can be used to reconnect.
• 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 an 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 referenced 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. There is now a team.svn at eclipse even if one piece needs to be downloaded from Polarion because of a LGPL license issue. Needs to be discussed how spaces is packaged and distributed.
• Publishing
  The publishing API is a highlevel api with methods like publishForProduction(File), publishForProduction(Folder) - see more below what the publishing functionality is about.
• HTTP access
  Optional. Allows access to the content via regular "read only" URLs.
• HTTPS access
  ?

This is perhaps a SPI? as a large part of publishing could be generic

• 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.

Publishing

A wizard helps with publishing with options:

• Select space (or take alternate route via creating account and creating space first)
• When a plug-in is published:
  • Should an OBR be created or an existing OBR be used, or perhaps no OBR?
  • Should an Eclipse feature be created or an existing feature be used, or perhaps no feature?
  • Should an Eclipse update site be created or an existing update site be used (both implies a feature), or no update site?
  • Should an Eclipse p2 profile be created or an existing p2 profile be used, or no p2 profile?
• If it is not a plug-in:
  • What kind of meta-data should be provided (name, version, type)
  • Documentation
  • Short-desc
  • Or appoint known meta-data format (cspec, POM, etc.)
• If no mapping is turned on for the space, the user is asked if they want to turn that on for the space (i.e. now do what they could do when adding the connection to the space in the first place. The user can also select "do not ask me again".

note: add info about "mapping" to creating/connecting to a space.

• A selection if the published material is for "test" or "production" (the implementation of the space publisher defines how this is mapped to the underlying technology). note about relationship between publishing and "reading/consuming" needs to be described

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

The user perspective

The user will perceive that the spaces concept consist of four things:

• Account and Space Management (Mandatory)
• Publishing (Mandatory)
• Source Code Management (Optional)
• Collaboration (Optional)

Consequently, instead of having Content Services, I think there should be a Publishing service that make it possible to upload new things to be visible on the web and a Source Code Management service that is based on SVN or CVS. I don't think there's a need for an unversioned Spaces Remote File System. In essence, this means that:

• If you want to share unversioned code, you do so by exposing source bundles using the Publishing Service
• If a provider wants to support the Source Code Management option, they will have to provide a SVN or CVS service.

Integrations between Source and Publishing

Let the Source Code Management service be aware of a top level project that contains the artifacts necessary to do a full build and then publish the result. We could provide ant-tasks for this so that everything can be controlled by ant and ultimately orchestrated by Buckminster.