Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib

["Joakim Högberg" <gokmase@gmail.com>]

>What I don't understand is why XaAES would have to be forked to remove
>WCOWORK.  If the application doesn't use it, then its not hurting
>anything to have it there.  If Windom doesn't want to support it, then
>Windom users won't use it.  Done deal.

Provided that the libraries are not taking over the job of the AES, and adding loads
of (perhaps) unneeded complexity, I would not expect any compatibility issues either.
I guess we will have to sit back and see where the discussion regarding these libraries
and their implementation takes us. A possibility to use modular approach without
shutting the door on improvements to the AES API would be highly welcome from my point of view.
Both as a user and a programmer.

>I don't see a problem with developing for the user.  The argument that
>current NAES and Magic users won't be able to run new software written
>to take advantage of the new AES features is quite simply stating a
>refusal to advance XaAES in any way.  No new features could be added at
>any time - so whats the point?   Might as well use an AES that hasn't
>been updated in 10 years - leave XaAES to the people that want to move
>forward!

Yes. And the new feature is an optional feature. If libraries are implemented in a neat way,
I imagine this should be quite possible to solve, if there is a will to do it.


Regards,

/Joakim