From mint-bounce@lists.fishpool.fi Wed Mar 16 16:24:43 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] State of the Union From: "Evan K. Langlois" To: Frank Naumann Cc: mint@fishpool.com In-Reply-To: References: <20050314031912.r4p1ykehn44googk@coolrunningconcepts.com> <1110945609.9126.54.camel@taro.coolrunningconcepts.com> <1110983111.11997.89.camel@taro.coolrunningconcepts.com> Content-Type: multipart/alternative; boundary="=-w2TVIdasN59t2tSW80A+" Organization: Cool Running Concepts Date: Wed, 16 Mar 2005 09:20:36 -0600 Message-Id: <1110986437.11997.93.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com 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.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, HTML_MESSAGE X-Spam-Level: --=-w2TVIdasN59t2tSW80A+ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-03-16 at 16:06 +0100, Frank Naumann wrote: > You got me wrong. I meant that it's not strictly necessary to wrap > appl_init, appl_exit and these things around a new interface because you > have to provide the old API for compatibility anyway. And using new > features require always a new API. I figured it would be easier to have one underlying API for testing and debugging and making sure things are compatible if you mix the old and the new. > My suggestion (for the new API) is a central, unified kernel event > interface for all types of events. Hmm .. so something completely new. I'll think about it. -- Evan --=-w2TVIdasN59t2tSW80A+ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-03-16 at 16:06 +0100, Frank Naumann wrote:

You got me wrong. I meant that it's not strictly necessary to wrap 
appl_init, appl_exit and these things around a new interface because you 
have to provide the old API for compatibility anyway. And using new 
features require always a new API.

I figured it would be easier to have one underlying API for testing and debugging and making sure things are compatible if you mix the old and the new.

My suggestion (for the new API) is a central, unified kernel event 
interface for all types of events.

Hmm .. so something completely new. I'll think about it.

-- Evan

--=-w2TVIdasN59t2tSW80A+--