[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] Reference Implementation Considerations
Hi Dennis,
thanks a lot for your comments.
I think this is a great summary of issues at hand with a reference
implementation. I think that I agree with a lot of the points and I would like
emphasize the importance of a proper intellectual property clearance
and licensing.
While I agree that SourceForge offers some of the tooling that is
required to develop
software in the open I would like to mention that a non-profit community
open source organization like the Apache Software Foundation has a number of
processes in place that make sure that the software produced
is created in a clean environment from IP [1] and Licensing [2] standpoint.
It is this very framework that allows all the commercial vendors to
participate without
the danger of any repercussions that we have all witnessed in recent
lawsuits like
the SCO v. IBM case [3].
I think the good news is that all the participating vendors in this TC
already have
active relationships with an organization like the Apache Software
Foundation either as
members, contributors, sponsors or simply licensing and redistributing software
built at the Apache Software Foundation.
Since I experienced some of the processes and legal implications that some of
the larger vendors have to go through if they want to participate in a
particular
open source development organization, having already an established relationship
in place is of tremendous value.
While I am particularly familiar with the processes at Apache based on my
experience there are a number of other non-profit organizations that are setup
very similarly like Mozilla[4], Eclipse [5] or FSF [6] (obviously some
of them with
a lot less commercial friendly licensing).
I am definitely looking forward to continue this conversation and maybe this
would be a good topic for the upcoming F2F.
regards,
david
[1] http://incubator.apache.org/ip-clearance/index.html
[2] http://www.apache.org/licenses/
[3] http://en.wikipedia.org/wiki/SCO_v._IBM
[4] http://www.mozilla.org/foundation/about.html
[5] http://www.eclipse.org/org/foundation/
[6] http://www.fsf.org/about/
On Mon, Dec 22, 2008 at 8:50 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> I was a little startled to see the discussion of reference implementations from Jens Hübel [1, 3] and David Nuescheler [2]. I had it in my head that a reference implementation is pretty far away from what fits under an OASIS TC activity. The chartered scope of the CMIS TC is entirely focused on the production and maintenance of specifications.
>
> At the same time, I think reference implementations are a great thing to have, and we could do with a lot more of them. So, without much consideration of the governance, charter, and OASIS suitability issues that there might be, here are the considerations that surfaced for me based on my previous thinking on this subject.
>
> - Dennis
>
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
>
>
> PS: After the discussion on today's call, I thought it worthwhile to post this much. I have been digging into the specification and I am now more convinced that a reference-implementation set might be called for. This will help us come to grips with problems around options, discoverability, and the heavy reliance on CMIS-opaque elements.
>
> - - - - - - - - - -
>
> GENERAL CONSIDERATIONS FOR CMIS REFERENCE IMPLEMENTATIONS
>
> 1. OPEN ISSUE: HOSTING OF REFERENCE IMPLEMENTATION ACTIVITY
>
> 1.1 The custodianship of reference implementations and their development process needs to be considered. It might be a non-OASIS activity even though member organizations of the CMIS TC are involved.
>
> 1.2 I favor creation of an open-source project on one of the public services for such activities. SourceForge seems to be a pet location for some interoperability-focuses projects.
>
> 2. OPEN ISSUE: PROPERTY RIGHTS IN THE REFERENCE IMPLEMENTATION
>
> 2.1 Ideally, the reference implementation, its documentation, supporting tools, and tests would be available in an open-source form that is congenial to making derivatives. The license should be compatible with derivates being made under reciprocal licenses such as the GPL. The license should also permit making derivates that are part of closed-source, commercial offerings without reciprocity. The OpenBSD license is found useful in this manner, it being the equivalent of the Creative Commons Attribution ("by") license for documents.
>
> 2.2 It is also important that a reference implementation not be encumbered by license requirements, so long as it and its derivatives implement CMIS specifications. If there are such requirements, I think that will be a non-starter. If the license becomes too complicated with regard to patent issues, that can be a problem too. (It is better if this part is handled with independent non-assert statements from those who might have applicable IP, with the usual trip-wire exception against parties who asserts an IP claim against an implementation.)
>
> 3. CHARACTERISTICS OF A REFERENCE IMPLEMENTATION
>
> My own thinking about reference implementations in a different context has led me to the following considerations. I think these resonate with but are not entirely congruent with those offered by Jens Hübel [1]:
>
> 3.1 The reference implementation must be a durable, usable artifact.
>
> 3.2 The reference implementation can be instrumented to assist in determining failures in access to its interface, in discrepancies in its own operation, and in failures in operation of fixtures that it is integrated above.
>
> 3.3 The software and documentation of the reference implementation are oriented to traceability of the specification into the implementation. The implementation is annotated to identify where there is essential behavior and where there is incidental behavior that is not compelled by the specification.
>
> 3.4 Where implementation-determined features can have lightweight or optional implementations, the reference implementation takes the simplest workable approach and incorporates an account for how that might be expanded in practice without dictating a more likely approach in production products. In all cases where there is optionality or necessity of implementation-determined traits, there is a careful account and reference to any available further guidance, informally-agreed practices, etc.
>
> 3.6 The reference implementation demonstrates an approach to the encounter of extensions and fall-back in the face of extensions or features that might not be supported. (This tends to be more about user agents and client-side behavior than the service-side approach of CMIS, but this should always be kept in mind in case there are provisions in a reference implementation that enhance the ability of clients to operate safely in the face of extension and restriction.)
>
> 3.7 The reference implementation might be modularized over time, with richer alternatives worked for certain cases. But it should always be possible to install, operate, and also port the simplest possible reference implementation. The CMIS specification is conducive to this approach, and that is extremely valuable because of the support for iterative development of richer reference implementations and production software too.
>
> 3.6 The reference implementation serves as an instance of a "product" against which a test library should succeed for the profile supported by a reference implementation installation.
>
> 3.7 The reference implementation serves as a basis for comparison with the functioning of a production CMIS integration and also with any effort to port the reference implementation itself into a different integration and/or platform.
>
> 3.8 The reference implementation may have opportunistic value as a working scaffolding for evolution to a desired production integration. (I suspect this may be of great value, especially for entry of smaller, specialized CMS products.)
>
> 3.9 It should be easy to place integrations of the reference implementation on-line for internet access for exercising and testing protocol behavior and operation with client-side integrations. It should be relatively easy to operate in a more-local setting for similar purposes (e.g., on an intranet, SOHO LAN, or a different process or virtual machine of a standalone computer).
>
> 4. CHALLENGES FOR CMIS REFERENCE IMPLEMENTATIONS
>
> I want to dig further into this, but I think there are the following matters of concern:
>
> 4.1 An appropriate architecture that separates concerns, especially between the service model and protocols and what is termed the data model in the CMIS specification.
>
> 4.2 Addressing authentication and authorization isolation as it is currently done in the CMIS 0.5 working document, with the likely unworkability of having a reference implementation that is ignorant of such provisions. This will provide some reality testing for the idea of having access-control be specifiable by user agents.
>
> 4.3 Discoverability at the user agent and the interchange of CMIS-opaque elements that (1) may be rejected by the data-model layer and need to be reported to an user agent in human usable terms.
>
> 4.4 Anticipation of internationalization (IRIs and what codes strings are in, opaque or not) and accessibility issues.
>
> Dennis E. Hamilton
> Seattle, Washington
> 2008-12-22
>
>
> [1] Jens Hübel: Thoughts about the reference implementation, 2008-11-24
> http://lists.oasis-open.org/archives/cmis/200811/msg00076.html
> I am sympathetic to a number of points here, although I also disagree on
> a couple of items. For me,
> - a reference implementation is not a substitute for a specification,
> although it is a very useful way to test the specification with a
> shared, inspectable worked-case
> - a reference implementation is not intended as a vehicle for code re-use,
> although it may be valuable in that context, especially as scaffolding
> for evolution into a production instance, and it may lead to design
> re-use in valuable ways
>
> [2] David Nuescheler: Re: Thoughts about the reference implementation, 2008-12-09
> http://lists.oasis-open.org/archives/cmis/200812/msg00038.html
> Without repeating the areas where I already disagree with Jens, I would add
> that
> - a test case is not a substitute for a specification either
> - I am not sure about functional completeness, especially if that obscures
> the clarity of the reference implementation and involves too much reliance
> on a particular implementation of an underlying CM system. I would want to
> be careful here and insist that the RI be a conforming implementation, but
> it need not be a fully-rich one to accomplish that
> - one might evolve some levels of reference-implementation versions, and how
> far one needs to take that may be a practical resolution of our concerns
>
> [3] Jens Hübel: Re: Thoughts about the reference implementation, 2008-12-12
> http://lists.oasis-open.org/archives/cmis/200812/msg00042.html
> - I think one does not want to build a CMIS-specific CM system as a reference.
> That seems t defeat the importance of showing that existing systems can have
> practical addition of a CMIS layer for interoperable use
>
> [end of Reference Implementation Considerations note]
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
--
Visit: http://dev.day.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]