You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rajath Shashidhara <ra...@gmail.com> on 2013/04/30 07:46:53 UTC
CMIS Universal Content Provider (UCP) for Apache OpenOffice
Hello Juergen,
I was suggested to look upon this idea by ariel because there are no
mentors available for my previous GSoC idea.
I looked up the ideas page for this idea.
Could you please shed some light on this topic?
I haven't worked with content management systems before.
What knowledge is required to quickly understand this in order to make a
worthy application?
--
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Jürgen Schmidt <jo...@gmail.com>.
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.rajaths@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 <or...@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.rajaths@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
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
2. Is there a way to edit the sidebar through the api?
On Thu, May 2, 2013 at 1:09 AM, Rajath Shashidhara <
rajaths.rajaths@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 <or...@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.rajaths@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
>
--
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani
Fwd: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
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 <or...@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.rajaths@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
RE: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by "Dennis E. Hamilton" <or...@apache.org>.
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.rajaths@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
Hello,
I found some information on:
http://www.openoffice.org/ucb/
I'll go through this.
On Thu, May 2, 2013 at 9:46 AM, Rajath Shashidhara <
rajaths.rajaths@gmail.com> wrote:
> Hello Ariel,
>
> Thanks.
> UCP is not a user-level application.
> My concept about UCP was not clear.
> I'll find out more about it.
> I'll look into the code that you have provided.
>
>
>
>
> On Thu, May 2, 2013 at 3:46 AM, Ariel Constenla-Haile <ar...@apache.org>wrote:
>
>> On Thu, May 02, 2013 at 03:25:54AM +0530, Rajath Shashidhara wrote:
>> > Hello Ariel,
>> >
>> > So if a document of unsupported type is selected for editing,
>> > The UCB will automatically reject it / display an error message.
>>
>> It's not the UCB, but a higher layer, that we usually call the
>> application framework, and is in charge of loading documents, with all
>> the things it implies.
>>
>> Let's say that the user wants to open a CMIS content, your CMIS UCP will
>> be queried for this content. At this step, you connect to the CMIS
>> repository (if authentication is required, it is handled by the usual
>> mechanism of the css.task.InteractionHandler).
>>
>> If the content exists, and it is a document, your CMIS content will be
>> asked to execute the "open" command (see the Basic code I posted in the
>> mail above). You simply provide a stream. You don't have to take care of
>> what happens from this point.
>>
>> > I don't have to do the filtering then?
>>
>> What do you mean by filtering? At this lower level, you simply handle
>> UCB contents that can execute commands.
>>
>> You don't even display any error message. All error handling at the UCP
>> level is done by throwing exceptions and using the interaction handler
>> mechanism.
>>
>>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
>>
>
>
>
> --
> 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
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
Hello Ariel,
Thanks.
UCP is not a user-level application.
My concept about UCP was not clear.
I'll find out more about it.
I'll look into the code that you have provided.
On Thu, May 2, 2013 at 3:46 AM, Ariel Constenla-Haile <ar...@apache.org>wrote:
> On Thu, May 02, 2013 at 03:25:54AM +0530, Rajath Shashidhara wrote:
> > Hello Ariel,
> >
> > So if a document of unsupported type is selected for editing,
> > The UCB will automatically reject it / display an error message.
>
> It's not the UCB, but a higher layer, that we usually call the
> application framework, and is in charge of loading documents, with all
> the things it implies.
>
> Let's say that the user wants to open a CMIS content, your CMIS UCP will
> be queried for this content. At this step, you connect to the CMIS
> repository (if authentication is required, it is handled by the usual
> mechanism of the css.task.InteractionHandler).
>
> If the content exists, and it is a document, your CMIS content will be
> asked to execute the "open" command (see the Basic code I posted in the
> mail above). You simply provide a stream. You don't have to take care of
> what happens from this point.
>
> > I don't have to do the filtering then?
>
> What do you mean by filtering? At this lower level, you simply handle
> UCB contents that can execute commands.
>
> You don't even display any error message. All error handling at the UCP
> level is done by throwing exceptions and using the interaction handler
> mechanism.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
--
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Thu, May 02, 2013 at 03:25:54AM +0530, Rajath Shashidhara wrote:
> Hello Ariel,
>
> So if a document of unsupported type is selected for editing,
> The UCB will automatically reject it / display an error message.
It's not the UCB, but a higher layer, that we usually call the
application framework, and is in charge of loading documents, with all
the things it implies.
Let's say that the user wants to open a CMIS content, your CMIS UCP will
be queried for this content. At this step, you connect to the CMIS
repository (if authentication is required, it is handled by the usual
mechanism of the css.task.InteractionHandler).
If the content exists, and it is a document, your CMIS content will be
asked to execute the "open" command (see the Basic code I posted in the
mail above). You simply provide a stream. You don't have to take care of
what happens from this point.
> I don't have to do the filtering then?
What do you mean by filtering? At this lower level, you simply handle
UCB contents that can execute commands.
You don't even display any error message. All error handling at the UCP
level is done by throwing exceptions and using the interaction handler
mechanism.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
Hello Ariel,
So if a document of unsupported type is selected for editing,
The UCB will automatically reject it / display an error message.
I don't have to do the filtering then?
On Thu, May 2, 2013 at 3:03 AM, Ariel Constenla-Haile <ar...@apache.org>wrote:
> Hi Rajath,
>
> On Wed, May 01, 2013 at 09:04:55PM +0530, Rajath Shashidhara wrote:
> > 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.
>
> Not only editing access, but access in general, as the content might be
> read-only.
>
> > 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.
>
> The last one is not your responsibility. The UCB will query your UCP for
> content X, using Apache Chemistry you will retrieve information about
> content X (the mime, if it is a folder or a file, etc.), and then the
> UCB will execute commands on the content.
>
> Browsing the repository will happen in the file picker (menu File
> - Open), this will end up calling your UCP to provide UCB-contents and
> execute commands on it (if the UCB-content is a folder, the UCB-content
> will be asked to list its contents; 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.
>
> Yes, Apache Chemistry comes with clear examples, that show most of what
> you will need to use. The hard part to understand is OpenOffice API ;)
>
> > But one thing I have not understood is:
> > A cmis repository can contains documents/folders/relationships/policies.
>
> Yes, you will represent the CMIS repository as a root folder with a set of
> documents and folders, something like the FTP-content provider in the
> diagram from
>
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/UCB/Universal_Content_Broker
>
> > But there is no mention about the kind/format of document for which the
> > support is required.
>
> The UCP is the lowest level, that means you know nothing about if a CMIS
> content can be "handled" by OpenOffice, that is, if OpenOffice can open
> it and display its contents to the user, this depends on a filter being
> available, but the UCP knows nothing about filters: you simply provide
> contents and execute commands on them.
>
> Answering your doubt above, you will have to support handling everything
> in the CMIS repository that can be represented as a folder or
> a file/document.
>
> > 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?
>
> No, it is something at a lower level: if a CMIS content represents
> a file/document and the user is trying to open it, the UCB will execute
> an "open" command on the CMIS-content; for you, this means only to
> provide the document's content as an stream, but you don't know if
> OpenOffice can handle it, this isn't your responsibility.
>
> > Do I have to deal with MIME Type of files to identify openoffice
> supported
> > files?
>
> The MIME type will be one of the properties you have to provide about
> a content. But you don't make any assumption about what OpenOffice will
> do with it, you simply don't care ;)
>
> The list of properties and commands an UCB-content should support are
> listed at
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/ucb/Content.html
> In trunk this documentation looks a little better:
>
> http://svn.apache.org/viewvc/openoffice/trunk/main/offapi/com/sun/star/ucb/Content.idl?revision=1460358&view=markup#72
> Though the trunk sdk does not work, you can get it only to read the
> docs.
>
> > I think I'm short of information and understanding to write a good
> > application.
>
> The UCB API is rather "complex". You may get a general understanding of
> how it works by playing with some AOO Basic code:
> http://people.apache.org/~arielch/api/UCB_demo.odt
> this code uses the WebDav UCP, you need a Developer Snapshot from
> a recent trunk, because it does not work on 3.4.1; but you can change
> the URLs and make them point to files on the local file system: the code
> is the same for all UCB contents.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
--
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Rajath,
On Wed, May 01, 2013 at 09:04:55PM +0530, Rajath Shashidhara wrote:
> 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.
Not only editing access, but access in general, as the content might be
read-only.
> 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.
The last one is not your responsibility. The UCB will query your UCP for
content X, using Apache Chemistry you will retrieve information about
content X (the mime, if it is a folder or a file, etc.), and then the
UCB will execute commands on the content.
Browsing the repository will happen in the file picker (menu File
- Open), this will end up calling your UCP to provide UCB-contents and
execute commands on it (if the UCB-content is a folder, the UCB-content
will be asked to list its contents; 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.
Yes, Apache Chemistry comes with clear examples, that show most of what
you will need to use. The hard part to understand is OpenOffice API ;)
> But one thing I have not understood is:
> A cmis repository can contains documents/folders/relationships/policies.
Yes, you will represent the CMIS repository as a root folder with a set of
documents and folders, something like the FTP-content provider in the
diagram from
http://wiki.openoffice.org/wiki/Documentation/DevGuide/UCB/Universal_Content_Broker
> But there is no mention about the kind/format of document for which the
> support is required.
The UCP is the lowest level, that means you know nothing about if a CMIS
content can be "handled" by OpenOffice, that is, if OpenOffice can open
it and display its contents to the user, this depends on a filter being
available, but the UCP knows nothing about filters: you simply provide
contents and execute commands on them.
Answering your doubt above, you will have to support handling everything
in the CMIS repository that can be represented as a folder or
a file/document.
> 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?
No, it is something at a lower level: if a CMIS content represents
a file/document and the user is trying to open it, the UCB will execute
an "open" command on the CMIS-content; for you, this means only to
provide the document's content as an stream, but you don't know if
OpenOffice can handle it, this isn't your responsibility.
> Do I have to deal with MIME Type of files to identify openoffice supported
> files?
The MIME type will be one of the properties you have to provide about
a content. But you don't make any assumption about what OpenOffice will
do with it, you simply don't care ;)
The list of properties and commands an UCB-content should support are
listed at
http://www.openoffice.org/api/docs/common/ref/com/sun/star/ucb/Content.html
In trunk this documentation looks a little better:
http://svn.apache.org/viewvc/openoffice/trunk/main/offapi/com/sun/star/ucb/Content.idl?revision=1460358&view=markup#72
Though the trunk sdk does not work, you can get it only to read the
docs.
> I think I'm short of information and understanding to write a good
> application.
The UCB API is rather "complex". You may get a general understanding of
how it works by playing with some AOO Basic code:
http://people.apache.org/~arielch/api/UCB_demo.odt
this code uses the WebDav UCP, you need a Developer Snapshot from
a recent trunk, because it does not work on 3.4.1; but you can change
the URLs and make them point to files on the local file system: the code
is the same for all UCB contents.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
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.
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Rajath,
On Wed, May 01, 2013 at 04:53:49PM +0530, Rajath Shashidhara wrote:
> Hello Juergen,
>
> Thank you for your previous mail.
>
> If I create a CMIS UCP for OpenOffice:
> What are the functions it is expected to have?
You have to design a UNO component that provides an implementation of
a com.sun.star.ucb.ContentProvider for CMIS.
http://www.openoffice.org/api/docs/common/ref/com/sun/star/ucb/ContentProvider.html
In order to understand what this means, first you have to learn what a UNO component
is, and then study how the UCB works.
Writing UNO components:
http://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Writing_UNO_Components
UCB:
http://wiki.openoffice.org/wiki/Documentation/DevGuide/UCB/Universal_Content_Broker
UCPs:
http://wiki.openoffice.org/wiki/Documentation/DevGuide/AppendixC/Universal_Content_Providers
> As in open/close/modify are the basic functions it is supposed to have.
> But, modify to what extent?
Technically speaking, you have to implement a ContentProvider, this is
the main entry point. And you have to define in a configuration file
what kind of protocol this ContentProvider can handle, for example
cmis:<server/repo/resource>.
When the application need to access a content with a URL that starts
with cmis:, the UCB will search in the configuration, will find your
content provider component, will instantiate it, and will ask it if it
can provide the desired content.
You will return an instance of a class implementing
a http://www.openoffice.org/api/docs/common/ref/com/sun/star/ucb/Content.html
It is the content who executes UCB commands, like "open", "delete",
"update", etc.
Use NetBeans to play with this skeleton
http://people.apache.org/~arielch/extensions/CMISContentProvider.zip
Debug the code in the target office, set a break point in
queryContent(), got to File - Open, and type cmis:///dummy (you may need
to select "Use OOo dialogs" from the Options dialog).
> My questions might be too basic. Sorry.
> I would like to access the source code of previously made UCP's.
> Where can I find them?
They are located in trunk/main/ucb/source/ucp. But this code uses lots
of helper classes in several modules. I'd suggest you start first with
plain/pure UNO, get an overview of how UCB works, and then look at the
C++ implementation only if necessary.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 1, 2013 at 7:23 AM, Rajath Shashidhara
<ra...@gmail.com> wrote:
> Hello Juergen,
>
> Thank you for your previous mail.
>
> If I create a CMIS UCP for OpenOffice:
> What are the functions it is expected to have?
>
> As in open/close/modify are the basic functions it is supposed to have.
> But, modify to what extent?
>
> My questions might be too basic. Sorry.
> I would like to access the source code of previously made UCP's.
> Where can I find them?
>
It is a a public holiday in Germany today (May 1st Labor Day) so
Juergen may be slow to respond.
You might look at the Apache Chemistry guide here for an overview of
the functionality on that end:
http://chemistry.apache.org/java/developing/guide.html
It is more than just read/write. There is the initial
authentication/connection, listing available files and folders,
navigating through folder hierarchies, creating folders, as well as
reading and writing files. Of course, permissions might be setup to
allow or disallow any of these. So you might need to react to the
case where a user can read and write in one folder but finds another
folder is read-only. And what about when creating a new document?
Should we allow setting of initial permissions then? Also, deleting a
file or folder is something to think about.
So how to decide? One approach might be to set up your own CMIS
server and try connecting to it from other client UI's. What do they
do well? What doesn't work well? Based on that investigation you
might have a better idea.
-Rob
>
> On Tue, Apr 30, 2013 at 7:53 PM, Rob Weir <ro...@apache.org> wrote:
>
>> On Tue, Apr 30, 2013 at 2:12 AM, Juergen Schmidt <jo...@gmail.com>
>> wrote:
>> > Hi Rajath,
>> >
>> > the UCB (universal content broker) defines an API to access files in
>> whatever file system, file storage etc. For each file store/system a UCP
>> (universal content provider) has to be implemented that implements the UCP
>> API. A UCP defines a special URL schema that triggers in the end the usage
>> of this UCP. For example http URLs used in a file open command are handled
>> by the WebDAV UCP. For the CMIS UCP I can think of a schema like
>> cmis://<server>/<file-root-node>/[<folder>]/<filename>[<parameters>] or
>> something like that. Internally such a URL gets analyzed and mapped on the
>> Chemistry library to access files or execute commands on files in a CMIS
>> supporting CMS. Results are mapped back and returned via the UCB API.
>> > Such a UCP allows to access files in a CMIS store directly via the
>> office internal file dialog or API's where a file URL is expected and it
>> make sense ;-)
>> >
>> > You will need to get familiar with CMIS, the Apache Chemistry library
>> and of course the office API, especially the UCB and UNO in general.
>> >
>>
>> Cool. I really like this proposal. It is a good mix of other Apache
>> technologies into OpenOffice.
>>
>> -Rob
>>
>>
>> > Juergen
>> >
>> >
>> > Am Dienstag, 30. April 2013 um 07:49 schrieb Rajath Shashidhara:
>> >
>> >> Hello Juergen,
>> >>
>> >> What are the things that must be implemented in the new ucp using apache
>> >> chemistry cmis?
>> >>
>> >>
>> >>
>> >> On Tue, Apr 30, 2013 at 11:16 AM, Rajath Shashidhara <
>> >> rajaths.rajaths@gmail.com> wrote:
>> >>
>> >> > Hello Juergen,
>> >> >
>> >> > I was suggested to look upon this idea by ariel because there are no
>> >> > mentors available for my previous GSoC idea.
>> >> >
>> >> > I looked up the ideas page for this idea.
>> >> >
>> >> > Could you please shed some light on this topic?
>> >> > I haven't worked with content management systems before.
>> >> > What knowledge is required to quickly understand this in order to
>> make a
>> >> > worthy 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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
> --
> Rajath S,
> M.Sc(Hons.) Physics,
> Birla Institute of Technology and Science - Pilani,
> Pilani
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
Hello Juergen,
Thank you for your previous mail.
If I create a CMIS UCP for OpenOffice:
What are the functions it is expected to have?
As in open/close/modify are the basic functions it is supposed to have.
But, modify to what extent?
My questions might be too basic. Sorry.
I would like to access the source code of previously made UCP's.
Where can I find them?
On Tue, Apr 30, 2013 at 7:53 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Apr 30, 2013 at 2:12 AM, Juergen Schmidt <jo...@gmail.com>
> wrote:
> > Hi Rajath,
> >
> > the UCB (universal content broker) defines an API to access files in
> whatever file system, file storage etc. For each file store/system a UCP
> (universal content provider) has to be implemented that implements the UCP
> API. A UCP defines a special URL schema that triggers in the end the usage
> of this UCP. For example http URLs used in a file open command are handled
> by the WebDAV UCP. For the CMIS UCP I can think of a schema like
> cmis://<server>/<file-root-node>/[<folder>]/<filename>[<parameters>] or
> something like that. Internally such a URL gets analyzed and mapped on the
> Chemistry library to access files or execute commands on files in a CMIS
> supporting CMS. Results are mapped back and returned via the UCB API.
> > Such a UCP allows to access files in a CMIS store directly via the
> office internal file dialog or API's where a file URL is expected and it
> make sense ;-)
> >
> > You will need to get familiar with CMIS, the Apache Chemistry library
> and of course the office API, especially the UCB and UNO in general.
> >
>
> Cool. I really like this proposal. It is a good mix of other Apache
> technologies into OpenOffice.
>
> -Rob
>
>
> > Juergen
> >
> >
> > Am Dienstag, 30. April 2013 um 07:49 schrieb Rajath Shashidhara:
> >
> >> Hello Juergen,
> >>
> >> What are the things that must be implemented in the new ucp using apache
> >> chemistry cmis?
> >>
> >>
> >>
> >> On Tue, Apr 30, 2013 at 11:16 AM, Rajath Shashidhara <
> >> rajaths.rajaths@gmail.com> wrote:
> >>
> >> > Hello Juergen,
> >> >
> >> > I was suggested to look upon this idea by ariel because there are no
> >> > mentors available for my previous GSoC idea.
> >> >
> >> > I looked up the ideas page for this idea.
> >> >
> >> > Could you please shed some light on this topic?
> >> > I haven't worked with content management systems before.
> >> > What knowledge is required to quickly understand this in order to
> make a
> >> > worthy 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 30, 2013 at 2:12 AM, Juergen Schmidt <jo...@gmail.com> wrote:
> Hi Rajath,
>
> the UCB (universal content broker) defines an API to access files in whatever file system, file storage etc. For each file store/system a UCP (universal content provider) has to be implemented that implements the UCP API. A UCP defines a special URL schema that triggers in the end the usage of this UCP. For example http URLs used in a file open command are handled by the WebDAV UCP. For the CMIS UCP I can think of a schema like cmis://<server>/<file-root-node>/[<folder>]/<filename>[<parameters>] or something like that. Internally such a URL gets analyzed and mapped on the Chemistry library to access files or execute commands on files in a CMIS supporting CMS. Results are mapped back and returned via the UCB API.
> Such a UCP allows to access files in a CMIS store directly via the office internal file dialog or API's where a file URL is expected and it make sense ;-)
>
> You will need to get familiar with CMIS, the Apache Chemistry library and of course the office API, especially the UCB and UNO in general.
>
Cool. I really like this proposal. It is a good mix of other Apache
technologies into OpenOffice.
-Rob
> Juergen
>
>
> Am Dienstag, 30. April 2013 um 07:49 schrieb Rajath Shashidhara:
>
>> Hello Juergen,
>>
>> What are the things that must be implemented in the new ucp using apache
>> chemistry cmis?
>>
>>
>>
>> On Tue, Apr 30, 2013 at 11:16 AM, Rajath Shashidhara <
>> rajaths.rajaths@gmail.com> wrote:
>>
>> > Hello Juergen,
>> >
>> > I was suggested to look upon this idea by ariel because there are no
>> > mentors available for my previous GSoC idea.
>> >
>> > I looked up the ideas page for this idea.
>> >
>> > Could you please shed some light on this topic?
>> > I haven't worked with content management systems before.
>> > What knowledge is required to quickly understand this in order to make a
>> > worthy 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Juergen Schmidt <jo...@gmail.com>.
Hi Rajath,
the UCB (universal content broker) defines an API to access files in whatever file system, file storage etc. For each file store/system a UCP (universal content provider) has to be implemented that implements the UCP API. A UCP defines a special URL schema that triggers in the end the usage of this UCP. For example http URLs used in a file open command are handled by the WebDAV UCP. For the CMIS UCP I can think of a schema like cmis://<server>/<file-root-node>/[<folder>]/<filename>[<parameters>] or something like that. Internally such a URL gets analyzed and mapped on the Chemistry library to access files or execute commands on files in a CMIS supporting CMS. Results are mapped back and returned via the UCB API.
Such a UCP allows to access files in a CMIS store directly via the office internal file dialog or API's where a file URL is expected and it make sense ;-)
You will need to get familiar with CMIS, the Apache Chemistry library and of course the office API, especially the UCB and UNO in general.
Juergen
Am Dienstag, 30. April 2013 um 07:49 schrieb Rajath Shashidhara:
> Hello Juergen,
>
> What are the things that must be implemented in the new ucp using apache
> chemistry cmis?
>
>
>
> On Tue, Apr 30, 2013 at 11:16 AM, Rajath Shashidhara <
> rajaths.rajaths@gmail.com> wrote:
>
> > Hello Juergen,
> >
> > I was suggested to look upon this idea by ariel because there are no
> > mentors available for my previous GSoC idea.
> >
> > I looked up the ideas page for this idea.
> >
> > Could you please shed some light on this topic?
> > I haven't worked with content management systems before.
> > What knowledge is required to quickly understand this in order to make a
> > worthy 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
>
>
Re: CMIS Universal Content Provider (UCP) for Apache OpenOffice
Posted by Rajath Shashidhara <ra...@gmail.com>.
Hello Juergen,
What are the things that must be implemented in the new ucp using apache
chemistry cmis?
On Tue, Apr 30, 2013 at 11:16 AM, Rajath Shashidhara <
rajaths.rajaths@gmail.com> wrote:
> Hello Juergen,
>
> I was suggested to look upon this idea by ariel because there are no
> mentors available for my previous GSoC idea.
>
> I looked up the ideas page for this idea.
>
> Could you please shed some light on this topic?
> I haven't worked with content management systems before.
> What knowledge is required to quickly understand this in order to make a
> worthy 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