Your questions are great! Kibitzing ...
BROAD CONSIDERATIONS If the CMIS repository supplies MIME type as an attribute, it would be useful to (tentatively) rely on that, especially for directory presentation. The ultimate confirmation, for ODF documents, will be with the "magic numbers" at the beginning of the file when it is retrieved for opening within Apache OpenOffice. The UCB basically expects to view Document Management systems as if they are (hierarchical) file systems, with presentation akin to a file-system explorer. There may be all manner of documents. Opening of an ODF-format document (or any document type that Apache OpenOffice can import) should probably happen in Apache OpenOffice (although, one could limit this or have user control on this). One could also limit this by relying on the local platform's file associations. Some DMS-integration schemes will allow opening in other applications when the document is not for the application that is providing access to the DMS. (The other application needs to be known to handle integration with the DMS because of any check-out/-in coordination and authentication that may be required.) The added complexity will have to do with login requirements of the repository, with check-out and check-in and also with versioning. There may be repository property sheets that may or may not be (partially) editable. This will also impact "recent documents" in Apache OpenOffice (and the operating-system) and whether or not re-opening via those paths work. NARROWING THE CONSIDERATIONS I think there is too much in the above for a first-pass via GSoC. It would probably be better to make a proof-of-concept/reference implementation that works with basic CMIS capabilities. A good challenge will be how to fail gracefully for cases that are not covered and for failures that occur. There is probably only so much that can be done via XContentProvider, and you'll want to minimize (or avoid altogether) creation of dialogs that come up from the CMIS adapter itself. Perhaps a key consideration is the cycle of how documents that are opened via the UCP are moved to the client file system and updates moved back to the repository. These will not have any encryption done at the repository. I'm not sure how integration with Save and Save As ... works via UCB, and also when the application is closing or has recovered after a crash. Some simple resilient approach that can be expanded on later might be good there. - Dennis -----Original Message----- From: Rajath Shashidhara [mailto:rajaths.raja...@gmail.com] Sent: Wednesday, May 01, 2013 08:35 To: dev Subject: Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice Hi Ariel, Thanks. As far as I have understood: A CMIS is a repository to store files and folders. I have to make a UCP which integrates into the existing UCB that provides editing access to files stored in the the CMIS repository by implementing XContentProvider interface. The things that I have to take care is the connection to the cmis repository, permissions to access files, querying content from the files, browsing through the repository to display the file hierarchy, etc. I browsed through some of the devguides of Apache Chemistry. The code was not too complex. I was able to follow the code - I could find the functions required to implement the above functions i the example code. But one thing I have not understood is: A cmis repository can contains documents/folders/relationships/policies. But there is no mention about the kind/format of document for which the support is required. Is it something like a openoffice format document is residing in the repository and I have to connect the already existing editing tools of openoffice to that file? Do I have to deal with MIME Type of files to identify openoffice supported files? e.g.: MIMEType: application/vnd.oasis.opendocument.text represents .odt format. Correct me if I'm wrong. I think I'm short of information and understanding to write a good application. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
