Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

[Suzy Deffeyes <[e-mail]>]

This begins to sound a bit like the OpenGL extension process. OpenGL's
process is a bit of overkill for our needs, but something similar might be
useful to us.

In OpenGL, a vendor can create a proprietary extension. It is named for the
vendor, so that potential users (ISVs) know it will probably not work on
other hardware.  If the vendor chooses to do so, the spec for that
proprietary extension can be made public. Occasionally two vendors will
cooperate on a spec,usually outside the OpenGL standards process, and can
put out a joint spec labeled EXT. When the OpenGL ARB (Architecture Review
Board) is ready to move an extension closer to being in the core, an ARB
labeled spec can be created, at this point the spec gets discussed,
designed, and voted on by the ARB. It is normal for widely implemented ARB
specs to eventually get rolled into core, at which point they are required
to be implemented by all vendors supporting that level of OpenGL.

>From a standards point of view, it helps weed out the features that aren't
widely implemented, and gives a spec time to evolve before it becomes part
of the required core.  Vendors can choose if there is value in trying to get
the extension widely used (by pushing it down the EXT/ARB path), or they can
choose to have it be super s3cr3t.  There is a naming convention that
indicates how widely available an extension is, and OpenGL licensees each
get their own block of enumerants so that extensions don't stomp on each
other.

>From an ISV standpoint, it's a little difficult to manage. An ISV might
implement their code using the EXT extension, and then not move to the ARB
or core versions of the functionality. That means that vendors end up
dragging around support for a lot of different extensions.

And FYI, in the COLLADA group we are also currently considering a more
formal extension mechanism as well.

Suzy Deffeyes/Pixel Gausman
IBM

On Wed, Apr 28, 2010 at 7:59 PM, John Hurliman <[e-mail]>wrote;wrote:

> +1 to moving forward with a bare minimum set of requirements. The trap I
> want to avoid is getting rough consensus that there are a ten different
> areas where we need to standardize communication, but when it comes time to
> actually doing the standards work it turns out only five of those areas are
> relevant to the active participants. The other five areas receive a fair
> dose of idle speculation, but otherwise go nowhere and stall the overall
> process.
>
> If anyone identifies a specific resource (service endpoint, set of
> endpoints, suite of bi-directional events, whatever) that they want to see
> standardized, I would prefer to see it drafted / prototyped / alpha tested
> before arguing that it should be officially sanctioned by VWRAP.
>
> John
>
>