From: Martin Stromberg Message-Id: <199910201252.OAA19463@propus.lu.erisoft.se> Subject: Re: /dev/zero support To: djgpp-workers AT delorie DOT com Date: Wed, 20 Oct 1999 14:52:36 +0200 (MET DST) In-Reply-To: from "Eli Zaretskii" at Oct 20, 99 01:01:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk I'm just brain storming a little here... Eli said: > On Mon, 18 Oct 1999, Richard Dawe wrote: > > I'm not sure I like the sound of this priority indicator - it sounds a bit > > too arbitrary. I'm sure it would be abused, not maliciously, just because > > it is easy to assume your module is the most important ;) > > If we design several standard priorities for extensions that are parts > of libraries, and document those priorities as "not for application > use", we can expect well-behaved libraries and applications to play by > the rules. Or if we realise (and accept) that we only need the distinction library FSEXT versus application FSEXT, there's no need to add a priority indication. The library should be able (manually) to define an order and make sure that one extension call the other which calls yet another in the right order. Right? Then the application installed FSEXT (of which there only can be one, like today) is always called last if the call hasn't been handled by the library FSEXT. After which, if it's stilled unhandled, is passed to DOZE. Pro: No interface change in application land. Con: Only one application FSEXT (like today). Perhaps a little more job adding yet another FSEXT to the library (the person adding a new FSEXT must find where in the library chain to insert his new FSEXT). U2, October, MartinS