From mint-bounce@lists.fishpool.fi Thu Oct 28 21:32:00 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <41814822.5010308@atari.org> Date: Thu, 28 Oct 2004 21:27:30 +0200 From: Odd Skancke User-Agent: Mozilla Thunderbird 0.8 (X11/20040928) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs References: <417CD550.80306@atari.org> <20041027172635.1489.qmail@mailcz.in.systinet.com> <417FE0B2.5010403@utbm.fr> <200410280115.29861.h.robbers@chello.nl> <20041028084227.K3028@muecke.local> <20041028152557.1 In-Reply-To: <20041028152557.17215.qmail@mailcz.in.systinet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=0.2 tagged_above=-50.5 required=3.8 tests=AWL, BAYES_00, NEW_DOMAIN_EXTENSIONS, RCVD_IN_SORBS X-Spam-Level: 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