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

Reply via email to