Re: [MiNT] WCOWORK vs WINDOM for components

[Mark Duckworth <mduckworth@atari-source.com>]

On Sat, 2005-07-23 at 13:57 -0600, evan@coolrunningconcepts.com wrote:

> Tell your computer science teacher you designed a system where the 
> parameters to
> your API change depending on a mode that not every module might 
> support, but you
> pass around the mode.
> 
> Not a consistent API.   BARF.  Only solution is to make sure no modules in the
> system use WCOWORK, or make sure none of them DON'T use it.
> 
> Back to the idea of overloading SHM with a plugin namespace, you'd have 
> WCOWORK
> and non-WCOWORK paths to separate the modules that can be loaded, and you'd
> better check the docs for anything you link with.

While I somewhat agree with what you're saying here, as we've learned in
the Atari world, the best way to do things for us may not be the
technically best way.  I haven't read these humongous emails full of
stuff I don't understand yet so I don't understand the specific
advantages to not changing the api, yet I believe they are probably
there.  In fact, I'm willing to bet one of the reasons to do it this way
is because it's simple and clean cut.  If you change the api, then every
gem lib will probably need recoded or recompiled to work at all with
xaaes still.  sounds stupid to me and very bad for our specific
community.

Most people code with a GEM lib of some sort.

GEM Lib supports WCOWORK
All apps under it support WCOWORK then... The API of the GEM libs can
change if that desire is there and most likely it will be.

GEM Libs are tied very close to the AES so this API distinction is not
necessary IMHO.  But I'm not ozk and he wins....  He's doing the work.

And I definitely don't think that we should behave as though Windom is
the only lib out there.  I have chosen to use Windom but MANY others
have not!  This obliterates all the work lp has done on his GFA gem lib,
It's not good for cflib and all the other libs out there.  

I can't say for sure whether I think the subwindow functionality should
belong in the gemlib or the aes but I trust ozk to make that decision.
Even if he's proven wrong later, what's the big deal?  We can change..
We're not a static binary only closed environment.

Please.. end this for the sake of everyone's sanity.  

Thanks,
Mark