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

[Rodrigo Hernandez]

I forgot what we were arguing about, I see your point, I would probably 
never need a C# interface, and thus I wasnt aware that was what you were 
looking after (sorry, you may have pointed that out before), I also see 
why you think ode.single and ode.double would be better than sufixes 
(makes for nicer looking assemblies), but I still think a unified 
library would be better in the long run (Think SSE implemented into 
different functions rather than clumsy #ifdef's).


Terry L. Triplett wrote:

> On 6/22/06, *Rodrigo Hernandez* <kwizatz at aeongames.com 
> <mailto:kwizatz at aeongames.com>> wrote:
>
>     Terry L. Triplett wrote:
>
>     > 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, 
>
>
> Grrr.  No, I"m *NOT* advocating a system-wide library in the sense 
> that you imply.  I want a viable mechanism for *shared* libraries with 
> clean versioning, which is a different thing. 
>
> I'm probably in the minority because as a maintainer of a library that 
> in turn supports downstream users, I have to speak in proxy as their 
> advocate.   They are depending on *me* to work things out.  That's 
> part of the responsibility I accepted when I stepped up to maintain a 
> project rather than just take, take, take.  And because I'm working in 
> an area not currently part of the greater collective consciousness, 
> the community is small.  Throw me a bone here, for god's sake!!  :-)
>
> I'm in the unenviable position of supporting a binding to ODE from a 
> higher level language (C# via P/Invoke) where static binding at 
> compile time is *not an option*.  Since binding happens at runtime, a 
> shared library is the only reasonable option.  The shared library 
> needs to have a clearly identifiable version so that in the context of 
> the wider system environment, the correct library is chosen, should an 
> ambiguity exist.
>
> You're confusing "System Wide Library" with "making a library 
> available to users via established mechanisms of distribution and 
> following established conventions".   A typical Linux distribution is 
> capable of supporting multiple library versions.  Applications and 
> packages that depend on a particular version of a library can depend 
> on them.  But where does the information about library versions come 
> from?  I maintain that this is the responsibility of the library 
> creators/maintainers.  That's where the questions/discussion about 
> sonames came from, not because I want to establish ODE as 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).
>
>
> An soname is useful/important for specifying changes to the API/ABI, 
> regardless of whether a library is "System Wide" or not (and remember, 
> a "System Wide Library" can exist in multiple versions).   It is still 
> useful/important for upstream users to be able to distinguish between 
> library versions - why not use the established, in-place mechanisms.  
> How else are the ODE developers keeping track of API/ABI changes?  
> Right now, it seems to me that it's via a seat-of-the-pants, "what 
> changed since the last release?  Do you know?  No, not me." mechanism. 
>
>     > 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.
>
>
> No, it's trying to establish a sane foundation based on established 
> principles of project management.  Arbitrary labels don't work well.  
> Defined goals do.  That's not an argument for the sake of arguing, 
> it's what any experienced project manager learns on the job.  Who in 
> the real world works on the basis of arbitrary labels as opposed to 
> specific requirements and goals? 
>
> Look, all of this talk isn't intended to slam the ODE maintainers for 
> the great job they are doing, it should be considered as feedback from 
> the ODE community from folks that are trying to get something done.  
> Being branded as a vocal minority isn't exactly motivation for 
> delivering ODE to a community of users that would otherwise not use 
> this great library.
>
> (In my darker moments, I think that a wrapper to ODE is a foolish 
> undertaking.  A 'native' C# physics library makes much more sense in 
> the long term.  Any takers?  I'm willing to give it a go ...)
>