You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Lennard Fuller <lf...@unicon.net> on 2010/03/24 01:31:50 UTC

Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?

I'm currently writing a cmis client, and opted to take advantage of the chemistry api as it has greatly eased development.  Since then I've noticed the addition of OpenCMIS and seen a good deal of activity around it.  It may be far too early to tell, but is there any idea which client side api the eventual Chemistry will most resemble?  The application I am working on is small, and refactoring to accommodate changes in the higher level api seem preferable to working directly with CMIS.
'Too early to tell' is a perfectly acceptable answer.

Any suggestions/recommendations are appreciated,
Lennard Fuller

Re: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?

Posted by Lennard Fuller <lf...@unicon.net>.
Thanks for the information, will watch the list closely for future developments.

-Lennard

----- Original Message -----
From: "Florent Guillaume" <fg...@nuxeo.com>
To: "chemistry-dev" <ch...@incubator.apache.org>
Sent: Wednesday, March 24, 2010 5:55:08 AM GMT -07:00 U.S. Mountain Time (Arizona)
Subject: Re: Am writing client code against the existing chemistry api...  should I switch to the OpenCMIS?

Adding to this, it should be mentioned that the high-level APIs of
Chemistry and OpenCMIS are really similar, so migrating from one to
the other (or to its merged successor) shouldn't be too much of a
problem.

I'm planning a wiki entry describing the API differences, and
proposals on how to keep the best of both in a merged version. I'll
inform this list when it's written.

Florent


2010/3/24 Jens Hübel <jh...@opentext.com>:
> HI Lennard,
>
> excellent question. I fear at the moment we can't give you the ultimate answer, but we can give you a couple of bits and pieces to consider:
>
> 1) We intend to join these two projects into one. But currently there is no roadmap how this should look like. We plan mid of April to start a discussion how we could join them and expect to give you a better answer then after this has happened.
>
> 2) None of the two is released so far. Because of this and because of 1) it is possible that any of the existing interfaces will be changed.
>
> 3) opencmis supports both AtomPub and web service today transparent to a user of the client API. There are two levels of the client API a provider interface (see provider packages) and a more convenient object-oriented client API (client packages). Currently the provider package is more mature than the client API, but the client API evolves quickly. See here (http://cwiki.apache.org/CMIS/opencmis-client-api.html) and here (http://cwiki.apache.org/CMIS/opencmis-provider-api.html)
>
> 4) There is a comparison sheet in the wiki between the two code streams: http://cwiki.apache.org/CMIS/chemistry-and-opencmis-comparison.html
>
> Let us know if you have more questions and it would be great to get feedback if you make your choice what your thoughts are.
>
> Jens
>
>
>
> -----Original Message-----
> From: Lennard Fuller [mailto:lfuller@unicon.net]
> Sent: Mittwoch, 24. März 2010 01:32
> To: chemistry-dev@incubator.apache.org
> Subject: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?
>
> I'm currently writing a cmis client, and opted to take advantage of the chemistry api as it has greatly eased development.  Since then I've noticed the addition of OpenCMIS and seen a good deal of activity around it.  It may be far too early to tell, but is there any idea which client side api the eventual Chemistry will most resemble?  The application I am working on is small, and refactoring to accommodate changes in the higher level api seem preferable to working directly with CMIS.
> 'Too early to tell' is a perfectly acceptable answer.
>
> Any suggestions/recommendations are appreciated,
> Lennard Fuller
>



-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Re: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?

Posted by Florent Guillaume <fg...@nuxeo.com>.
Adding to this, it should be mentioned that the high-level APIs of
Chemistry and OpenCMIS are really similar, so migrating from one to
the other (or to its merged successor) shouldn't be too much of a
problem.

I'm planning a wiki entry describing the API differences, and
proposals on how to keep the best of both in a merged version. I'll
inform this list when it's written.

Florent


2010/3/24 Jens Hübel <jh...@opentext.com>:
> HI Lennard,
>
> excellent question. I fear at the moment we can't give you the ultimate answer, but we can give you a couple of bits and pieces to consider:
>
> 1) We intend to join these two projects into one. But currently there is no roadmap how this should look like. We plan mid of April to start a discussion how we could join them and expect to give you a better answer then after this has happened.
>
> 2) None of the two is released so far. Because of this and because of 1) it is possible that any of the existing interfaces will be changed.
>
> 3) opencmis supports both AtomPub and web service today transparent to a user of the client API. There are two levels of the client API a provider interface (see provider packages) and a more convenient object-oriented client API (client packages). Currently the provider package is more mature than the client API, but the client API evolves quickly. See here (http://cwiki.apache.org/CMIS/opencmis-client-api.html) and here (http://cwiki.apache.org/CMIS/opencmis-provider-api.html)
>
> 4) There is a comparison sheet in the wiki between the two code streams: http://cwiki.apache.org/CMIS/chemistry-and-opencmis-comparison.html
>
> Let us know if you have more questions and it would be great to get feedback if you make your choice what your thoughts are.
>
> Jens
>
>
>
> -----Original Message-----
> From: Lennard Fuller [mailto:lfuller@unicon.net]
> Sent: Mittwoch, 24. März 2010 01:32
> To: chemistry-dev@incubator.apache.org
> Subject: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?
>
> I'm currently writing a cmis client, and opted to take advantage of the chemistry api as it has greatly eased development.  Since then I've noticed the addition of OpenCMIS and seen a good deal of activity around it.  It may be far too early to tell, but is there any idea which client side api the eventual Chemistry will most resemble?  The application I am working on is small, and refactoring to accommodate changes in the higher level api seem preferable to working directly with CMIS.
> 'Too early to tell' is a perfectly acceptable answer.
>
> Any suggestions/recommendations are appreciated,
> Lennard Fuller
>



-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

RE: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?

Posted by Jens Hübel <jh...@opentext.com>.
HI Lennard,

excellent question. I fear at the moment we can't give you the ultimate answer, but we can give you a couple of bits and pieces to consider:

1) We intend to join these two projects into one. But currently there is no roadmap how this should look like. We plan mid of April to start a discussion how we could join them and expect to give you a better answer then after this has happened.

2) None of the two is released so far. Because of this and because of 1) it is possible that any of the existing interfaces will be changed.

3) opencmis supports both AtomPub and web service today transparent to a user of the client API. There are two levels of the client API a provider interface (see provider packages) and a more convenient object-oriented client API (client packages). Currently the provider package is more mature than the client API, but the client API evolves quickly. See here (http://cwiki.apache.org/CMIS/opencmis-client-api.html) and here (http://cwiki.apache.org/CMIS/opencmis-provider-api.html)

4) There is a comparison sheet in the wiki between the two code streams: http://cwiki.apache.org/CMIS/chemistry-and-opencmis-comparison.html

Let us know if you have more questions and it would be great to get feedback if you make your choice what your thoughts are.

Jens



-----Original Message-----
From: Lennard Fuller [mailto:lfuller@unicon.net] 
Sent: Mittwoch, 24. März 2010 01:32
To: chemistry-dev@incubator.apache.org
Subject: Am writing client code against the existing chemistry api... should I switch to the OpenCMIS?

I'm currently writing a cmis client, and opted to take advantage of the chemistry api as it has greatly eased development.  Since then I've noticed the addition of OpenCMIS and seen a good deal of activity around it.  It may be far too early to tell, but is there any idea which client side api the eventual Chemistry will most resemble?  The application I am working on is small, and refactoring to accommodate changes in the higher level api seem preferable to working directly with CMIS.
'Too early to tell' is a perfectly acceptable answer.

Any suggestions/recommendations are appreciated,
Lennard Fuller