...
- 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.
...