Reference implementation: Difference between revisions

Revision as of 15:49, 6 February 2016

Revision as of 21:54, 8 February 2016

Line 1:

In the [[software development process]], a '''reference implementation''' (or, less frequently, ''sample implementation'' or ''model implementation'') is the standard from which all other implementations and corresponding customizations are derived. An improvement to a reference implementation reflects an unchanging [[specification (technical standard)|specification]]. Conversely, a failed attempt at an implementation may prove that the specification is not suitable and needs improvement itself. [[Software testing|Testing]] the implementation-vs.-specification relationship further enhances the [[Product family engineering|production]]'s inter-process efficiencies:

{{quote|A reference implementation is, in general, an implementation of a specification to be used as a definitive interpretation for that specification (This definition is a bit grandiloquent but works). During the development of the ... conformance test suite, at least one relatively trusted implementation of each interface is necessary to (1) discover errors or ambiguities in the specification, and (2) validate the correct functioning of the test suite.<ref>Dalci, Eric; Fong, Elizabeth; Goldfine, Alan (2003). ''Requirements for GSC-IS Reference Implementations''. National Institute of Standards and Technology, Information Technology Laboratory. [http://xw2k.sdct.itl.nist.gov/smartcard/document/ref-imp51.pdf]</ref>}}

Line 10:

# Helps to clarify the intent of the specification in situations where [[Conformance testing|conformance tests]] are inadequate<ref>Curran, Patrick (2003). ''Conformance Testing: An Industry Perspective''. Sun Microsystems. [https://web.archive.org/web/20120303000051/http://vote.nist.gov/speeches/1%20-%20Specification%20Panel/6%20-%20Curran.pdf]</ref>}}

Reference implementations of algorithms, for instance [[cryptographic algorithm]]s, are often the result or the input of [[standardization]] processes. In this function they are often dedicated to the [[public ___domain]] with their [[source code]] as [[public ___domain software]]. Examples are the first [[CERN HTTPd|CERN's httpd]],<ref>[http://web.archive.org/web/20140817185526/http://home.web.cern.ch/topics/birth-web/licensing-web The birth of the web Licensing the web] on cern.ch (2014)</ref>, [[Serpent (cipher)|Serpent]] cipher, [[base64]] variants,<ref>[http://libb64.sourceforge.net/ libb64] on sourceforge</ref>, and [[SHA-3]].<ref>[http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip KeccakReferenceAndOptimized-3.2.zip] mainReference.c ''"The Keccak sponge function, designed by Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche. For more information, feedback or questions, please refer to our website: http://keccak.noekeon.org/Implementation by the designers, hereby denoted as "the implementer". To the extent possible under law, the implementer has waived all copyright and related or neighboring rights to the source code in this file. http://creativecommons.org/publicdomain/zero/1.0/"''</ref> The [[Openwall Project]] maintains a list of several algorithms with their reference [[source code]] in the public ___domain.<ref>[http://openwall.info/wiki/people/solar/software/public-___domain-source-code Source code snippets and frameworks placed in the public ___domain] on [[Openwall Project|openwall.info]]</ref>

A reference implementation may or may not be production quality. For example, the [[Fraunhofer Society|Fraunhofer]] reference implementation of the [[MP3]] standard usually does not compare favorably to other common implementations, such as [[LAME]], in listening tests that determine sound quality.{{factcitation needed|date=January 2012}}

==References==