From:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
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:	<Pine.SUN.3.91.991020130127.22660B-100000@is> from "Eli Zaretskii" at Oct 20, 99 01:01:56 pm
X-Mailer:	ELM [version 2.4 PL24]
MIME-Version:	1.0
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

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

- Raw text -