Hi Rajath,

first of all welcome at Apache OpenOffice. It's good to read that you
are interesting in the CMIS proposal and that you have already started
to learn more about.

You have already got some very useful hints from Ariel and pointers
where to start. I suggest that you take a closer look in this stuff.

The Chemistry project provides code to run your own CMIS test server
which is probably a good idea to get started and to work on the UCP.
This way you can easy cross check  other clients or can even debug the
server to see what's coming in from your UCP.

On 5/1/13 9:42 PM, Rajath Shashidhara wrote:
> Hello Juergen,
> 
> I had a irc chat with Alexandro about this project.
> He asked me two questions and told me to confirm it from you:
> 1. He asked me if I can use the pre-existing auth api from openoffice to
> authenticate to cmis repository

whatever Alexandro did mean here I don't know. The UCB has some
interaction handler that are responsible for authentication and yes this
concept can and have to be reused and you have to implement the
interaction handler requests for the authentication and other
interactions. You will learn about it in time


> 2. Is there a way to edit the sidebar through the api?

You can create an own new panel for the sidebar via API and the content
of the panel is provided via UNO AWT toolkit. Means yes you use the API
to create a new panel.
But first you should focus on the UCP that can b used via the office
file open dialog. Additional commands like checkin/checkout should be
handled by the UCP as well and can be tested via the plain UCB API from
Basic or any other helper extension for example. Ariel showed you
already how to use the API from Basic.

Besides the standard UCB commands your UCP can support further CMIS
specific commands. The advantage of defining and using UCB commands is
that later the file picker can be extended to support them as well.

Juergen


> 
> 
> On Thu, May 2, 2013 at 1:09 AM, Rajath Shashidhara <
> rajaths.raja...@gmail.com> wrote:
> 
>> 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
>>
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to