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: Thoughts about the reference implementation

Hi all,


I would like to continue the discussion about the reference implementation and compatibility test kit that we started in the call today. Even that OASIS does not require it we should carefully consider having something like this. I understand all the issues mentioned in the call today and faced them in the same way in my company as well. However we should not neglect the other side:

·        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.

·        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)

·        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.  Instead it should be easily modifiable and implemented in something giving you high productivity. 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.

·        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) .


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.




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