Hello Everyone, I have spent a considerable amount of time writing a well thought out application for this project. Please suggest the changes in the timeline & implementation details.
*Project Description:* Ideas Page Link: https://issues.apache.org/jira/browse/COMDEV-78 *Technical Description of the Project:* To create an extension containing a Java UNO Component which is a Universal Content Provider which integrates into already existing UCB of the Apache OpenOffice, which provides a content provider for Content Management Systems using OpenCMIS(OpenContent Management Interoperability Systems) for editing of documents stored on a OASIS compliant CMIS repository. A sidebar through which the user can browse and access the fucntions of CMIS repository is also to be created. *Advantages of this feature*: 1. Access and edit documents stored on remote servers. 2. Collaborative editing. 3. Version Control. *My Solution to the project:* Modules used: OpenCMIS Java API, OpenOffice Java UNO component. Functions that are added to OpenOffice: 1. Connect to the CMIS repository (login may be required). 2. Browse through the file hierarchy of the repository. 3. Open a file for editing. 4. Delete a file. 5. Change meta-data of file. 6. Change file permissions. 7. Check-in/Check out file (Lock file editing to restrict the editing to one person at a time). 8. Version Control features like revert changes. 9. Save file in a repository. (Both Save and Save as in a repository)* 10. List the file in recent documents of OpenOffice.* *Deliverables:* A Java extension to provide UCP for CMIS under Apache License 2.0 *Timeline:* 1st Week: Creating the module which allows user to authenticate to CMIS repository; Acquiring the file hierarchy of the repository. (Modules sent for review). 2nd Week: Filtering the file hierarchy for file formats that are supported by OpenOffice based on Magic Numbers/MIME Type. Retrieving the file based on user's choice for editing. (Reviewed Modules received - Changes Made). (Module sent for review.) 3rd Week: Locking in/Locking out of documents. Adding the code which checks for file permissions before allowing files for editing. (Reviewed Modules received - Changes Made). (Module sent for review.) 4th Week: Deleting - Modifying the metadata of documents. Updating the local changes made to a file in the repository. (Buffer Space) 5th Week: (Buffer Space). All modules reviewed and Documented. Preparation for Midterm evaluations. 6th Week: Adding version control features like Reverting changes made to a file - includes listing all the recent changes made to the file and an option to revert back. (Module sent for review). 7th Week: Designing and Coding of sidebar UI for user control. (Changes made after review). (Module sent for review). 8th Week: Adding save/save as to repository feature. Adding the files accessed from repository to recent documents list. (Buffer Space). 9th Week: (Buffer Space). Integrating all modules to build a UCP. Integrating it to UCB. 10th Week: Debugging, Documenting. Review of extension. (GSoC Done!!!). * - Features to be implemented only if the timeline goes according to the plan. On Wed, May 1, 2013 at 10:13 PM, Dennis E. Hamilton <orc...@apache.org>wrote: > 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. > > -- Rajath S, M.Sc(Hons.) Physics, Birla Institute of Technology and Science - Pilani, Pilani -- Rajath S, M.Sc(Hons.) Physics, Birla Institute of Technology and Science - Pilani, Pilani
