Standa Opichal wrote:
Hi!There are two different points of view on this. One with which you would extend AES API and another (my proposed pipes) with which you would make FreeMiNT apps aware of that there is a OS compatible input point _file_ (pipe in this case) where you can detect AES activity. My point is that we can get the functionality without extending event_multi() API as that one is ugly enough already.
I dont think extending evnt_multi() will be a poblem, if thats what we choose to do. What is so ugly about evnt_multi() btw? I'm thinking about a whole new function for XaAES aware apps, xevnt_multi(), which we can design to our liking.
Well, this is rather phylosophical question: * Make the AES which has a SingleTOS design more UNIXish?
XaAES aint got no SingleTOS design :) Think about what we can do for apps in the 'XaAES domain'.
OR* Provide UNIXish way to detect AES events (pipes) and call the good 'old' AES interface afterwards...
This sounds messy to me. I think a good design is to NOT mix two layers of the operating systems like this.
As I don't like extending event_multi() or creating a new AES API extension (of course you can consider the pipes an API too, but I see it being different) for this I would vote to implement the pipe solution into AES.
Well... how about creating a new AES API alltoghether, and make that available to 'XaAES domain' clients? However, I think we should get XaAES up to n.aes stability before we discuss such things.
Regards Odd Skancke