Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3D325D41.4050809@apache.org>
Date: Sun, 14 Jul 2002 22:27:29 -0700
From: Ian Holsman <ianh@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020713
MIME-Version: 1.0
To: rbb@covalent.net, dev@apr.apache.org
Subject: Re: IO abstraction layer for files
References: <3D321D1B.2000800@apache.org> <00b001c22ba3$d5c7a610$0a01230a@KOJ>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ryan Bloom wrote:
> We had an IO abstraction layer a long time ago.  The original one was
> bulky, hard to debug, and didn't solve the problem it was designed to
> solve, namely filtering.  When the filters were introduced, the IOLs
> were removed, because they were no longer needed.
> 
> I guess my only question, is what problem are you trying to solve with
> an IOL?  Until we have an answer to that, there is really no way to know
> if they are a good idea or not.  Every time that they have come up in
> the past, the reason was never enough to justify adding the complexity
> and performance problems.  Remember that in general, an IOL would mean
> that every time you wanted to read to or write from a file or network,
> you would do a pointer de-ref and call an extra function.

I'm  thinking of how you would implement a event driven MPM, where you 
wouldn't want a module to block on a read.
AND not have the module designers have to rewrite their modules

--Ian

> 
> Ryan
> 
> ----------------------------------------------
> Ryan Bloom                  rbb@covalent.net
> 645 Howard St.              rbb@apache.org
> San Francisco, CA 
> 
> 
>>-----Original Message-----
>>From: Ian Holsman [mailto:ianh@apache.org]
>>Sent: Sunday, July 14, 2002 5:54 PM
>>To: dev@apr.apache.org
>>Subject: IO abstraction layer for files
>>
>>I know this topic has come up several times in the past,
>>but I can't remember the outcome/reasoning on why we didn't
>>want to re-introduce the IO Layer for file operations..
>>
>>TIA
>>Ian
> 
> 
>