[ODE] On the meaning of ODE stability (was some quick notes on 0; 6) ...

[Jon Watte (ODE)]

Each game will depend on specific bugs and quirks of specific versions 
of ODE. A systemwide ODE shared library isn't all THAT useful in general 
(other than as a checkmark), and is downright detrimental to software 
compatibility moving forward.

Look what they did to D3DX: one new DLL every 2 months. d3dx9_24.dll, 
d3dx9_25.dll, d3dx9_26.dll, ... and Microsoft has a LOT more people to 
spend on ensuring games compatibility than ODE does. Let's put the 
gunpowder where it matters (like collisions, joint types, etc).

Cheers,

          / h+


Rodrigo Hernandez wrote:
> Terry L. Triplett wrote:
>
>   
>> On 6/22/06, *Rodrigo Hernandez* <kwizatz at aeongames.com 
>> <mailto:kwizatz at aeongames.com>> wrote:
>>
>>
>>     Well, there is one single reason I (and others) think ODE should
>>     not be
>>
>>
>> Who are these mysterious others?  Will they not reveal themselves?   :-)
>>     
>
> You alone seem to be  the vocal minority who advocates for a system wide 
> library, I remember John Watte supporting the
> position that a System Wide library was a bad idea the second to last 
> time we discused sonames, (forgive me John if I am mistaken).
>
>   
>>     part of a distribution, and that is the dual library aproach.
>>     which one should you distribute? double or single precision? both? if
>>     you decide for either, some will require the other, if you go for
>>     both,
>>     then we need to decide on how will we be distinguishing them, make
>>     build
>>     changes and so on, this isnt imposible, and maybe not hard, but not
>>     exactly easy.
>>
>>
>> Not much in life is easy if worthwhile.  Suck it up and make a decision.
>>
>> At the present state of technology?  Both, I'd say. 
>>
>> Distinguished by name (e.g. ode-single-<version>.<foo> and 
>> ode-double-<version>.<foo>, where foo is the designation for shared or 
>> static libraries on appropriate platforms).  Both produceable by a 
>> single build step (ie, building ODE by default gives you both). 
>>
>> Having a clear choice of which precision to link to (dynamic linking) 
>> or include (static linking) for a C++ library at development time is 
>> better than having things blow up in your face because the wrong 
>> precision was used against the single ODE library that was available.
>>
>>     
> We need to have a consensus, its not just "suck it up and make a 
> decision", specialy since I think a single library with precision sufixes is
> better than a library for each precision.
>
>   
>>     Which brings me to a point I wanted to present for a while.
>>     I think we should standarize the function names so that there is a
>>     single library with single and double precision calls, much
>>     like OpenGL "f" and "d" suffixes, just throwing the idea into the
>>     air here.
>>
>>
>> And what about quad precision and beyond?  ( 
>> http://en.wikipedia.org/wiki/Quad_precision).  As technology 
>> advances,  notions like precision based on the number of storage 
>> locations in memory seem quaint.  Pretty soon there will need to be 
>> "q" and "whatever" suffixes as well. 
>>
>> Ultimately, the answer is likely to be multiprecision, arbitrary 
>> precision data types.  Until then we have to live with what the 
>> language and compiler designers give us.
>>
>>     
> Jason answered this one.
>
>   
>>     As for 1.0, I dont see it as just a label, I think once 1.0 is
>>     reached,
>>     the library would be a full feature library with a stable, standarized
>>     API, 1.1 being backward compatible with it and so on, this is just my
>>     opinion though.
>>
>>
>> I guess I'd have to see a targeted feature list to be able to 
>> interpret what "full feature" would mean.  1.0 *is* just a label, even 
>> if it resonates with our human perception of numbers. 
>>
>> No matter what the label (ODE-1.0, or 
>> ODE-745.453.3452.I_AM_REALLY_STABLE_HONEST_TRUST_ME), it is the agreed 
>> upon development objective(s), not the label, that defines stability 
>> and full featuredness.
>>
>> Targeting features rather than labels is a better path for this kind 
>> of project, IMHO.
>>     
>
> True, I am not going to argue with you here, as this seems to be arguing 
> just for the sake of arguing.
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
>