[dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support for workspaces

[Randall Hauch (JIRA)]

    [ https://jira.jboss.org/jira/browse/DNA-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12452466#action_12452466 ] 

Randall Hauch commented on DNA-281:
-----------------------------------

Each connector can choose to support workspaces in a couple of different ways.

The connector framework supports the ability to discover the workspaces that are available in a source (or, rather, that are available to the supplied ExecutionContext).  In general, the connector would simply return the set of names of existing workspaces, where "existing" means something meaningful to the connector.  For example, the JPA Store connector allows defining on the source instance the names of some "predefined" workspaces; these workspaces don't need to be created by the client, becuase the connector always behaves as though those workspaces exist, even if they haven't yet been accessed or initialized.

The connector framework also supports the notion of a default workspace.  Basically, this is simply a way of allowing a connector to say which workspace should be used if none is specified by the client.  However, all requests require a non-null workspace name, with one exception: the VerifyWorkspaceRequest is intended to allow the client to verify that a workspace exists.  If the name of the workspace is null, the connector is free to respond with an error or to choose an existing workspace to use.

The ability to create new workspaces is defined as a new connector capability, so it's possible for connector implementations to not support creating new workspaces and to simply define the existing workspaces that are available.  The SVN connector is one example that might make use of this approach, since the workspaces might be defined by the (existing) branches and tags.  (Although branching could be implemented via cloning of a workspace, but this is probably beyond what's needed/desired.)

A connector implementation can combine these characteristics to produce a wide range of support.  For example, a connector that doesn't really support workspaces really supports just one (which should also be the default) and doesn't support creating new workspaces, cloning workspaces, or destroying existing workspaces.  On the other hand, a connector could support multiple workspaces and even allow the client to define new or cloned workspaces.  Or, as with the SVN connector, the connector may support multiple workspaces but may not allow clients creating, cloning or destroying workspaces.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira