[cmis] api and general structure, client implementation

[David Nuescheler <da...@day.com>]

hi all,

i think we are making great progress on the server side of the cmis
implementation and it is great to see both the ws and the atompub
binding progress so quickly.

since i think it should also be a goal of this implementation to
make our code as re-uable as possible, it is great that it does
not have any specific proprietary jackrabbit dependencies but
really just jcr dependencies. on top of that i think it would also
be great to expose the entire cmis model as a separate api.

i think dominique already submitted an issue around specifying
an api, so both the ws and the atompub binding can use that.

https://issues.apache.org/jira/browse/JCRCMIS-7

i would like to take that a step further and also propose that we
have a cmis client. i think this is something that is really important
and help everybody developing something around cmis a great
deal.

so. i would propose that we have an svn subproject structure
that is something like this.

jcr-cmis/
  server/
  client/
  api/

does that make sense?

regards,
david

-- 
Visit: http://dev.day.com/

Re: [cmis] api and general structure, client implementation

[Dominique Pfister <do...@day.com>]

Hi,

On Tue, Jan 13, 2009 at 2:13 PM, Paolo Mottadelli <pa...@gmail.com> wrote:
> Hi all,
>
> On Mon, Jan 12, 2009 at 9:36 AM, David Nuescheler <da...@day.com> wrote:
>> since i think it should also be a goal of this implementation to
>> make our code as re-uable as possible, it is great that it does
>> not have any specific proprietary jackrabbit dependencies but
>> really just jcr dependencies. on top of that i think it would also
>> be great to expose the entire cmis model as a separate api.
>
> Yes, this is what we were thinking about, as well; thinking of naming
> it 'model'. So let's go with the 'api' one; I totally agree.
>

Cool, I'll add a submodule 'api' then, as a sibling to 'server'.

>
>> i would like to take that a step further and also propose that we
>> have a cmis client. i think this is something that is really important
>> and help everybody developing something around cmis a great
>> deal.
>> so. i would propose that we have an svn subproject structure
>> that is something like this.
>
> I think that the client subproject could be structured as a sort of
> TCK for our server implementation; in that case it should be
> structured to support generic functionalities and could be, one day, a
> useful tool for other implementations.
>
> WDYT?

I think that's a very good point. I especially like the idea of adding
test cases for actual and future parts of the specification.

Cheers
Dominique

>
> --
> Paolo Mottadelli: http://www.paolomottadelli.com
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>

Re: [cmis] api and general structure, client implementation

[Paolo Mottadelli <pa...@gmail.com>]

Hi all,

On Mon, Jan 12, 2009 at 9:36 AM, David Nuescheler <da...@day.com> wrote:
> since i think it should also be a goal of this implementation to
> make our code as re-uable as possible, it is great that it does
> not have any specific proprietary jackrabbit dependencies but
> really just jcr dependencies. on top of that i think it would also
> be great to expose the entire cmis model as a separate api.

Yes, this is what we were thinking about, as well; thinking of naming
it 'model'. So let's go with the 'api' one; I totally agree.


> i would like to take that a step further and also propose that we
> have a cmis client. i think this is something that is really important
> and help everybody developing something around cmis a great
> deal.
> so. i would propose that we have an svn subproject structure
> that is something like this.

I think that the client subproject could be structured as a sort of
TCK for our server implementation; in that case it should be
structured to support generic functionalities and could be, one day, a
useful tool for other implementations.

WDYT?

-- 
Paolo Mottadelli: http://www.paolomottadelli.com
Sourcesense - making sense of Open Source: http://www.sourcesense.com