1<html> 2 3<head> 4<title>Promoting OpenGL Extensions</title> 5</head> 6 7<body> 8<h1>Promoting OpenGL Extensions</h1> 9 10<p> <i>Promoting</i> an extension refers to moving it from single-vendor 11to multi-vendor or ARB-approved status, usually by changing the vendor 12tag attached to the extension name string, enumerants and API entry 13points. This is sometimes done when an extension is successful and more 14licensees want to support it. This document describes the steps to 15follow when promoting an extension. 16 17<h3>Is Promotion Required?</h3> 18 19<p> Changing the names creates a significant burden for ISVs supporting 20the existing extension. It should not be done gratuitously; if the 21existing interface is sufficient, there's no inherent reason an 22implementation shipped by one vendor cannot advertise and support an 23extension using another vendor's prefix. 24 25<p> If you do this, make <b>certain</b> that the original vendor agrees 26to freeze the definition of the extension, and that what you ship is 27identical in behavior to what the original vendor is shipping. Shipping 28what appears to be the "same" extension while implementing different 29behavior on multiple platforms is a great disservice to ISVs trying to 30use extensions, and to OpenGL in general. 31 32<p> <b>Do not</b>, under any circumstances, ship an extension defined by 33another vendor without first clearing it with that vendor. 34 35 36<h3>Promoting Without Changes in Behavior</h3> 37 38<p> If you nevertheless want to promote an extension from 39vendor-specific to e.g. <tt>EXT</tt> status, without changing the 40behavior or definition of that extension, then advertise and export 41<b>both</b> the old and the new forms of the extension for maximum 42backwards compatibility. This means that: 43 44<ul> 45 <li>Both extensions strings should be included in the 46 <tt>GL_EXTENSIONS</tt> string query (or the corresponding 47 WGL/GLX query, if it extends those APIs). 48 <li>All enumerants should exist in both 49 <tt>GL_<i>VENDOR</i>_ENUM_NAME</tt> and 50 <tt>GL_EXT_ENUM_NAME</tt> forms, with the same values. 51 <li>All entry points should exist in both 52 <b>glExtensionName<i>Vendor</i></b> and 53 <b>glExtensionNameEXT</b> forms, resolving to the same code. 54 <li>For an extension supported under GLX, the same GLX protocol 55 should be generated no matter whether the vendor or <tt>EXT</tt> 56 version of the extension is called. 57</ul> 58 59 60<h3>Promoting With Changes in Behavior</h3> 61 62<p> If you are promoting an extension while changing its definition or 63behavior, <b>do not</b> treat it as identical to the old extension. This 64means that: 65 66<ul> 67 <li>Any new <tt>EXT</tt> enumerants which differ in definition from 68 the original <tt><i>VENDOR</i></tt> enumerants should be assigned new 69 values, and those values registered with SGI. 70 <li>All new <b>EXT</b> entry points should resolve to different code 71 in the GL client library than the original <b><i>Vendor</i></b> 72 extension entry points. 73 <li>For an extension supported under GLX, different GLX protocol 74 requests should be generated for the two extensions, so 75 they can be distinguished on the server side. 76</ul> 77 78<p> None of this should be taken to indicate that code cannot be shared 79between implementations of the old and new extensions; simply that the 80implementation must be able to distinguish whether the old or new form 81is being called, since they are de facto different extensions despite 82sharing similar purposes. 83 84<hr> 85 86<p> Last modified April 5, 1999 Jon Leech 87</body> 88</html> 89