OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cmis] Thoughts about the reference implementation


Thanks David,

one more comment (I think you missed the last call): We did not discuss this topic much, but someone mentioned Apache Jackrabbit as a potential candidate. It wouldn't be a repository designed specifically around CMIS. But on the other hand much would already be available, the license would be what we have in mind and it could proof the integration with JSR very well. We should spend some more thoughts on this option.

Jens


-----Original Message-----
From: David Nuescheler [mailto:david@day.com] 
Sent: Dienstag, 9. Dezember 2008 15:18
To: Jens Hübel
Cc: CMIS TC List
Subject: Re: [cmis] Thoughts about the reference implementation

Hi Jens,

thanks a lot for your post.

> A specification will never be 100% precise and explicit. Having
> something available as code that in doubt gives at least one answer is a
> good thing.
I absolutely agree.

> We must ensure that things we put in the specification are
> implementable.
> Having something that we can use to play with and potentially try
> out different ideas of how to specify something (e.g. ACLs) would be highly
> beneficial. Having the possibility to share a piece of code within the TC as
> part of an environment everyone is familiar with would be a great benefit
> for our TC. Sometime 5 lines of code are just more than 1000 words. If we
> need to decide between multiple alternative proposals looking at the various
> implementation of something will often make finding a decision easier (how
> much code does it need to implement this, how can the code be structured, is
> it maintainable/understandable)
Agreed. I would add that sometimes a simple "testcase" can say more than
1000 words in a spec.

> Very often errors, unclear phrases and issues are detected during
> development. Forcing us to put every bit and piece it into code before
> making it standard just gives us and others confidence. In my opinion pure
> interoperability tests never can replace this (but instead cover another
> dimension).
> The scope of the reference implementation could be limited. I would
> not expect an implementation ready for productive use, highly scalable and
> performing.
I very much agree on performance, scalability etc.

In my mind a reference implementation would have to be functionally complete,
in the sense that it complies with 100% of the functions described in
the specification.
Other standards bodies mandate that the RI passes all of the tests in a TCK
which I think is definitely valuable. Otherwise the RI can cut corners in the
areas where the specification becomes hard to implement, which
talks to your point about making sure that the specification is implementable.

> Instead it should be easily modifiable and implemented in
> something giving you high productivity.
I would add that it has to be code that is explanatory and features a lot
of proper inline documentation.

> I would consider here modern
> scripting languages like Ruby or Groovy for example. With the nice
> integration of Hibernate in Grails for example it should be possible to
> quickly come to some first results.
> In previous discussions we identified areas that each and everyone
> has to implement again. I recall the parser for the query grammar as one
> example. Having something available on a (or more) widely used platform/s
> would save a lot of work when implementing the standard and would be one way
> to make CMIS a success.
I personally, don't care too much about the implementation language.
For some of the components that we want to have some re-use I think
it probably would make sense that they be written in Java / C# right?
(What do others think that they would like their CMIS components to
be written in?)

> Having something small and lightweight and implement CMIS and only
> CMIS is for me something preferable to a full blown repository with tons of
> stuff in there and CMIS as one component on top even if this repository is
> available as open source (from a CMIS standardization perspective of course)
I completely agree that for a reference implementation it does not make
sense to be implemented against any particular proprietary repository.
And I agree, just the fact that the source code is publicly available does not
mean that the repository implementation is less proprietary.

> If we come to the conclusion that a full blown reference implementation is
> not feasible, maybe we find a way just to cover some of these aspects.
> Something like a code repository, playground whatever.
> Again this is just to bring some more aspects into the discussion. It would
> be nice to hear some more comments/thoughts from others as well.
I think I agree with all of the above statements. Good points.
Thanks for starting the discussion.

regards,
david


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]