CMIS Proposal (Deprecated)

Scope of change: Major
Champion Name: Eric Woods (IBM)
Spec Editors: Eric Woods
Ref implementation: Apache Shindig 3.0

Δ NOTE: This page has been deprecated.  Refer to the new CMIS documentation page: http://docs.opensocial.org/display/OSD/CMIS+Use+Cases+and+Positioning

Purpose1

Given that we have a number of vendors that are actively working on products and solutions that use both OpenSocial and CMIS, and similar concepts appear in each spec, our goal is to provide a consistent, open, standards-based programming model that leverages the strengths of each specification, promotes interoperability, and fosters sharing and collaboration among communities.

Since our goal is to align CMIS & OpenSocial to avoid duplicate data models and concepts, I propose we displace OpenSocial's existing Albums & MediaItems constructs with CMIS Folders & Documents, respectively.

Approach

Step1: Proof of Concept

As a first pass, we aligned OpenSocial Albums & MediaItems with CMIS Folders & Documents, respectively. Our goal was to develop a POC that leverages the overlap between the two specifications by implementing an OpenSocial gadget that interacts with Albums & MediaItems, but whose data is persisted in a CMIS-compliant repository on the back-end. Our implementation leverages Apache Shindig as the OpenSocial container and Apache Chemistry (OpenCMIS) as the CMIS repository. All work was conducted in the open via open source. The implementation was in Apache Shindig.

Specifically, we wrote a utility that maps OpenSocial Albums & MediaItems to CMIS Folders & Documents, respectively.  This utility was plugged into Apache Shindig.  When a client gadget performs CRUD operations on Albums or MediaItems, these Albums & MediaItems were mapped to CMIS Folders & Documents on Shindig's back-end.  These Folders & Documents were then persisted in a CMIS repository.  This enables the client gadget to function the same regardless of sample JSON database or CMIS repository back-end (i.e. the gadget simply talks to the Albums & MediaItems API, which doesn't change).  See all related links in the "Completed Steps" section below.

Note: The code to support this effort was last updated in October of 2010.  The structure of Shindig (specifically ActivityStreams) has changed substantially since then.  Getting the demo to work will require updates and merging.

Completed Steps

  • Analyze current mapping between CMIS Documents and OpenSocial MediaItems: Mapping from Albums & MediaItems to Folders & Documents
  • Write bi-directional mapping utility that maps Albums/MediaItems to Folders/Documents and vice-versa.
  • Implement the Albums & MediaItems services within Apache Shindig: Reference Implementation
  • Build OpenSocial gadget to demonstrate complementary APIs: Screenshots,Reference implementation
  • Implement CMIS mapping utility within Apache Shindig; maps Albums & MediaItems to Folders & Documents: Patch
  • Integrate ActivityStreams with CMIS binding; Albums & MediaItems CRUD generates ActivityStreams: Patch

Step 2: Reference Implementation

This section will be updated with patch links once the reference implementation has been completed.

  1. Implement Document & Folder data types
  2. Implement Document & Folder services (service, handler, JSON DB)
  3. Implement Document & Folder tests

Step 3: OpenSocial Adoption

This section will be updated once the reference implementation has been completed.

  1. Draft Folders, Documents, and their respective services into the OpenSocial specification.
  2. Follow OpenSocial specification procedures to officially adopt these data types and services.

Proposed Specification Changes

Services API

I propose the Albums & MediaItems services are deprecated in place of Documents & Folders services, which will follow OpenSocial API conventions.  Per OpenSocial convention, the opts parameter defines attributes such as the userId and groupId and CRUD operations return an osapi.Request object.

Folders API

CRUD

  • Get Folder: osapi.folders.get(opts);
  • Create Folder: osapi.folders.create(opts);
  • Update Folder: osapi.folders.update(opts);
  • Delete Folder: osapi.folders.delete(opts);

Example GET request to retrieve all John's Folders:

osapi.folders.get({userId: 'john.doe'}).execute(function(resp) {
  alert(resp);
});

Documents API

CRUD

  • Get Document: osapi.documents.get(opts);
  • Create Document: osapi.documents.create(opts);
  • Update Document: osapi.documents.update(opts);
  • Delete Document: osapi.documents.delete(opts);

Example GET request to retrieve all John's Documents:

osapi.documents.get({userId: 'john.doe'}).execute(function(resp) {
  alert(resp);
});

Example GET request to retrieve all of John's Documents within Folder identified by 'MyPics':

osapi.documents.get({userId: 'john.doe', folderId: 'MyPics'}).execute(function(resp) {
  alert(resp);
});

Document Data Type

TODO (Eric W.)

Folder Data Type

TODO (Eric W.)

Additional Considerations

  • Allow nested folders?  If so, how do we ID a folder since names may be duplicated.  Fully qualified path e.g. /johnspics/germany?
  • How to define CMIS repository to persist documents/folders into?  Part of Document/Folder data type, or is this handled elsewhere?