Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[corona-dev] Corona Collaboration Context to JCR Mapping

We are investigating the use of Jackrabbit a JCR (JSR-170) compliant repository as a repository for holding items associated with a Collaboration Context.  These are questions I had while I was reading through the JCR specification.  I apologize for the random nature.

 

Should we revamp the existing Corona Repository Interface to be a subset of the JCR API?  The current Corona Repository Interface is very simple but not very powerful. 

Is the session interface and workspace interface general enough to replace Repository Interface

 

The JCR Session Api looks similar:

getRepository

getItem

itemExists

 

Should  we just expose the JCR Session interface and the Workspace interface using the Corona SOA support as web services?

 

It looks like there can be an almost direct mapping from Eclipse objects to JCR objects:

            Eclipse Workspace   è JCR Workspace

            Eclipse Projects è        ??? JCR Nodes

            Eclipse Folders  è JCR Nodes

            Eclipse Resource è JCR Property (PropertyType.BINARY)

 

How should we handle a ContextContainer – should we store it in the JCR Jackrabbit repository?  Review section 5.4 of JCR Spec (jsr170-1.0.pdf)

 

            ContextContainer è JCR Workspace

            RepositoryDescriptor è JCR Node (with name Property)

            RepositoryConfigurations è JCR Node

            RepositoryConfiguration è JCR Node

            RepositoryConnection è JCR Node

            RepositoryConnectionParameters è JCR Node

            RepositoryConnectionParameter è JCR Property

            RelatedContainers è JCR Node???

            RelatedContainerUri è JCR Reference Property (section 4.9.1.2)

 

Jackrabbit is JCR level 2 compliant how well does it support Workspace versioning?

Can we take advantage of Workspace versioning to help synchronizing Cached Context Container and Server Context Container?

 

Should we change the Repository Interface to closely match the Eclipse and wrap the JCR API’s to fit into the Eclipse API’s?

org.eclipse.core.resources.IFile;

org.eclipse.core.resources.IFolder;

org.eclipse.core.resources.IProject;

org.eclipse.core.resources.IProjectNature;

rg.eclipse.core.resources.IResource;

org.eclipse.core.resources.IResourceChangeEvent;

org.eclipse.core.resources.IResourceDelta;

 

JCR allows Nodes in one Workspace to reference nodes in another Workspace does it make sense to create multiple projections of the documents contained in the Repository.

 

The idea is to create “physical” layout Workspace for the documents perhaps by document type.

Then define Workspace based upon defined roles that reference nodes in the “physical” Workspace

For example, we could create specific Workspaces for people with the roles: Analyst, Architect, Developer, Tester, Operations (Deployment)

Each Workspace could be tailored to fit the role.

Perhaps the Role-base Workspace could be dynamically modified by monitoring items accessed/changed by people in difference roles

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Back to the top