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

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

Hi,

>> Don't you think it's a good remark ? If a new feature mainly introduce  
>> incompatibility and nothing for the user, then it's a bad feature... and  
>> it's my feeling about WCOWORK.
>
>There is no incompatibility at the user level, except that XaAES is
>needed and not N.AES or MagiC

Quite right. And I am getting 100% sick of hearing "nothing for the user".
Any change in the API will in the long run affect the work done by coders,
and therefore also the users. The benefits of the WCOWORK mode are there,
even if they are not important to everyone.

I don't judge other features saying they offer "nothing for the user", even if I personally
could not care less about eg. if there is a possibility to display a background picture on
the menubar. Different features applies to different ppl, be it coders or users.
I hope we can agree on that?

>> All these libraries are independant and don't know what other libraries  
>> do. If one piece of code enable the WCOWORK feature, then all the  
>> libraries will get into trouble because values returned by some AES  
>> functions depend on that mode.
>
>Not if your library is written right.

Here I can't agree more! Surely there must be better ways to carry out the
otherwise excellent idea with using dedicated libraries than this?

If not, what about adding a possibility for a user process to enquire whether or not
a certain AES process is running in WCOWORK mode or not? However, I would
absolutely prefer a solution where libraries could handle this correctly on their own.

IMO it does not feel right to restrict the AES because a library designs has limitations!

>And when will a library component do this?  This seems like a contrived
>example for a library that isn't doing its abstractions properly.

I agree.

>> The *only* problem is that some data may now have two differents meanings  
>> depending on the WCOWORK mode. Without this mode, the meaning of the data  
>> is clearly defined and may be safely used by any piece of code.

Yes, but most of those definitions were made a long time ago, and certainly not made
with the dynamic library idea in mind. I would guess that noone ever guessed that these
AES calls was never intended to be used in this manner at all. This is something we have
to consider regardless of what extentions we wish to add to the OS in any way IMO.


regards,

/Joakim