Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Spaces/Naming"

Line 2: Line 2:
 
=Spaces URI=
 
=Spaces URI=
 
A Spaces URI consists of the following:<br/>
 
A Spaces URI consists of the following:<br/>
<tt>:spaces:<i>provider scheme</i>:<i>location</i>:<i>space</i></tt>
+
<tt>:spaces:<i>provider scheme</i>:<i>authority</i>:<i>space path</i></tt>
 +
 
 +
As an example:
 +
<pre>
 +
:spaces:xdrive:fred@aol.com/space1
 +
</pre>
  
 
==spaces==
 
==spaces==
The spaces part is a keyword - it identifies the URI as specific to spaces.
+
The spaces part is a keyword - it identifies the URI as specific to spaces. The part that follows the "spaces" part should be a valid hierarchical URI such that:
 +
<pre>
 +
URI x = URI.create(<i>full address</i>);
 +
URI y = URI.create(x.getSchemeSpecificPart());
 +
</pre>
 +
Both URI's x and y are valid, and y is hierarchical.
  
 
==provider scheme==
 
==provider scheme==
 
A provider scheme is a scheme such as "local", "svn", "aol", "sourceforge". A plugin that provides a serviceProvider extension declares that it handles a particular provider scheme. At any given time there can only be one registered service provider extension for a provider scheme.
 
A provider scheme is a scheme such as "local", "svn", "aol", "sourceforge". A plugin that provides a serviceProvider extension declares that it handles a particular provider scheme. At any given time there can only be one registered service provider extension for a provider scheme.
  
==location==
+
==authority==
The format of the "location" part is determined by the service provider extension, and can can have any URI valid format. The only rule is that the very last part of the URI is reserved for the space name.
+
The format of the "authority" part should conform to URL rules regarding authority. This part is optional. It is used to differentiate between spaces for different users on different domains/servers - fred's space "space1" for fred@aol.com, is clearly a different space than "space1" for "john@aol.com"
  
 
By convention, the location is on the format:<br/>
 
By convention, the location is on the format:<br/>
<tt><i>account</i>@<i>address</i></tt>
+
<tt><i>account</i>@<i>address</i>[:port]</tt>
 +
 
 +
Where <i>account</i> typically is a user specific part, and <i>address</i> is the address of a service provider. An optional ":port" may be used, and a service provider may use this - spaces currently treats two space addresses that only differ by port to mean a reference to the same space.
 +
 
 +
==Space Path==
 +
A space path is a pointer to where the space is to be found within the realm defined by "spaces:provider:authority". Some provider may have an implementation where all spaces are at the root of that realm, others may provide a realm where spaces can be located more freely in a naming structure.
 +
 
 +
The "LocalSpaceProvider" that provides access to spaces in the local file system is such a provider. A space path for the local provider is just the path to a directory; e.g. <tt>:spaces:local:user@localhost:/tmp/space1</tt>
  
Where <i>account</i> typically is a user specific part, and <i>address</i> is the address of a service provider.
 
 
=Hierarchical URI=
 
=Hierarchical URI=
If a hierarchical URI is used from "provider scheme" forward, it is possible to reuse generic wizards for certain operations.
+
Since a hierarchical URI is used from "provider scheme" forward, it is possible to reuse generic wizards for certain operations.
If a space provider needs to - an opaque URI can be used, but then wizards and API's are needed to be able to perform some
+
operations.
+
  
 
=Examples=
 
=Examples=
Line 38: Line 52:
  
 
etc.
 
etc.
 +
=Good space names=
 +
It is a good idea to name spaces using the same type of naming given to java packages.
 +
e.g.
 +
 +
<tt>:spaces:svn:henrik@demo.org:/spaces/org.demo.spacedemo</tt>

Revision as of 19:43, 20 January 2008

This is a proposal for naming in spaces

Spaces URI

A Spaces URI consists of the following:
:spaces:provider scheme:authority:space path

As an example:

:spaces:xdrive:fred@aol.com/space1

spaces

The spaces part is a keyword - it identifies the URI as specific to spaces. The part that follows the "spaces" part should be a valid hierarchical URI such that:

URI x = URI.create(<i>full address</i>);
URI y = URI.create(x.getSchemeSpecificPart());

Both URI's x and y are valid, and y is hierarchical.

provider scheme

A provider scheme is a scheme such as "local", "svn", "aol", "sourceforge". A plugin that provides a serviceProvider extension declares that it handles a particular provider scheme. At any given time there can only be one registered service provider extension for a provider scheme.

authority

The format of the "authority" part should conform to URL rules regarding authority. This part is optional. It is used to differentiate between spaces for different users on different domains/servers - fred's space "space1" for fred@aol.com, is clearly a different space than "space1" for "john@aol.com"

By convention, the location is on the format:
account@address[:port]

Where account typically is a user specific part, and address is the address of a service provider. An optional ":port" may be used, and a service provider may use this - spaces currently treats two space addresses that only differ by port to mean a reference to the same space.

Space Path

A space path is a pointer to where the space is to be found within the realm defined by "spaces:provider:authority". Some provider may have an implementation where all spaces are at the root of that realm, others may provide a realm where spaces can be located more freely in a naming structure.

The "LocalSpaceProvider" that provides access to spaces in the local file system is such a provider. A space path for the local provider is just the path to a directory; e.g. :spaces:local:user@localhost:/tmp/space1

Hierarchical URI

Since a hierarchical URI is used from "provider scheme" forward, it is possible to reuse generic wizards for certain operations.

Examples

spaces:svn:henrik.lindberg@spaces.cloudsmith.com:/demo

  • spaces - keyword
  • svn - use the space provider implementation for generic svn
  • henrik.lindberg - the name of the user's account
  • spaces.cloudsmith.com - location where the generic svn space is to be found
  • /demo - the name of the space

spaces:local:demo

  • spaces - keyword
  • local - use the space provider implementation for local file system
  • (empty) - the local scheme assumes "current user" and "localhost"
  • demo - name of the space

etc.

Good space names

It is a good idea to name spaces using the same type of naming given to java packages. e.g.

:spaces:svn:henrik@demo.org:/spaces/org.demo.spacedemo

Back to the top