Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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

...

USA Toll-Free: 888-426-6840
USA Caller Paid: 215-861-6239
For Other Countries: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=3295259&accessNumber=2158616239
Participant Code: 3295259

...

Introduction

A number of folks have been interested in aligning CMIS and OpenSocial.  While there was an initial prototype of this done earlier this year, we need to take the next step and document the base set of use cases and high-level positioning.

...

Many enterprise social platforms have some basic form of file management, and increasingly, OpenSocial is becoming part of the programming model that these platforms offer for integration at the application (gadget) layer, as well as the server to server integration layer (REST). Increasingly, customers of both CMIS systems, and social platforms are expecting these two systems to "just work together". By aligning with CMIS, the OpenSocial community will get the benefit of a more complete, feature rich data model that can easily be plugged in at the server layer with a CMIS system. The CMIS community benefits by having a rich social model that can be used to foster collaboration around the content that resides in their systems. The open ecosystem of vendors, application developers, and customers benefits by having clearly defined boundaries among standards, a consistent Web 2.0 social application model, and perhaps most importantly, an open standards based integration path for enterprise systems.

Use Cases

Document & Folder CRUD Operations

Explain basic crud use case in more detail here.

...

When the CMIS browser binding is approved and CMIS repositories support its capability, HTTM HTTP form posts may be used to upload document content.  Until then, a mechanism will have to be established to retrieve the bits from the user's local machine and upload them to the PUT link.

...

CMIS supports the notion of document sub-types, which inherit certain properties and attributes from their parents.  Sub-types may require certain properties/attributes to be defined in order to create documents of that type.  We must, at minimum, allow gadget developers to retrieve the repository's sub-types and metadata to facilitate creation of those sub-types.

CMIS Queries

CMIS supports querying, such as full text searching within CMIS documents.  For the first pass, OpenSocial will not support querying operations (subject to change).

...

Deprecating Albums and Media Items

As a result of this effort, there will no longer be a need for the OpenSocial specification to carry forward the definition and APIs for Album and Media Item. As such, they will be deprecated when support for the new APIs & data model that is based on CMIS is introduced. Whenever possible, we'll outline the migration path from the old APIs to the new data model. In addition, there are social constructs that will be carried forward and remain the responsibility of the OpenSocial based container.

Meeting Minutes

12/06/2011

...

Setup

  1. Check out Apache Shindig.
  2. Apply Download and apply CMIS patch to Shindig.
  3. Build Apache Shindig.
  4. Deploy Shindig to your favorite application server.
  5. Check out Apache Chemistry.
  6. Build Apache Chemistry using Maven.
    1. Via command line, navigate to the checked out Chemistry project.
    2. Run: mvn clean install -Dmaven.test.skip=true
  7. Deploy Apache Chemistry's in-memory repository to your favorite application server.
    1. The WAR file is located under chemistry-opencmis-server > chemistry-opencmis-server-inmemory > target.
    2. The patch is currently hardcoded to look for a CMIS repository at http://localhost:8081/repository, so deploy the WAR to port 8081 with context root "repository".
    3. For more information, refer to Chemistry's documentation for building and deploying the in-memory repository.
  8. Deploy Apache Chemistry's browser tool.
    1. The WAR file is located under chemistry-opencmis-test > chemistry-opencmis-test-browser-app > target.
    2. E.g. http://localhost:8081/repository/browser/
  9. Restart servers.
  10. Confirm environment setup.
    1. Point your browser to the CMIS browser tool (e.g. http://localhost:8081/repository/browser/browse)
    2. Enter *http://localhost:8081/repository/atom* into  into the browser tool.
    3. Verify you can browse the CMIS repository using the tool.
    4. Point your browser to the OpenSocial documents service (e.g. http://localhost:8080/social/rest/documents/john.doe/@self/1/)
    5. Verify that john's documents are returned (John may not have any documents, but shouldn't thrown an error).

...

  • Posts a document for John Doe.  The document's parent is identified by parentId [OSD:required].
  • Example minimal POST body:

...

  • I used Apache Chemistry's InMemory Repository to build this patch.  It's appropriate because it's lightweight and resets all data on each restart, like Shindig's JSON DB.
  • The CMIS repository is currently hardcoded to point to http://localhost:8081/repository/atom in JsonDbOpensocialService.java.  To change the repository, change this hardcoding (near the bottom of the file).
  • The OpenSocial sample JSON DB is only persisting document & folder IDs; no document & folder metadata are being persisted in the JSON DB.  This is to circumvent caching issues.  If another user changes a document on the CMIS back-end, the OpenSocial metadata will become stale.  By only persisting the document/folder ID, the latest document/folder metadata is retrieved from the server on each request.
  • Despite only folder/document IDs being persisted in the social container, these IDs may still become out-of-sync with the CMIS back-end.  For example, a user creates several documents using the OpenSocial APIs.  The OpenSocial container is then restarted, losing the user's records of those documents.  The documents will still be persisted in the CMIS repository, but a GET via the OpenSocial APIs will return an error because the container does not have a record of the user owning the file.  As a work-around, a PUT request may submitted via the OpenSocial API, inserting a record of the user owning the file with the container.  From there, subsequent GETs, PUTs, and DELETEs will work as expected.
  • For convenience, several document and folder IDs should be pre-populated in Shindig's canonicaldb.json database so that GET calls return several objects by default.  These IDs should align with Chemistry's in-memory repository default sample documents & folders.

...