Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <rbb@covalent.net>
From: "Ryan Bloom" <rbb@covalent.net>
To: "'Ian Holsman'" <ianh@apache.org>,
	<dev@apr.apache.org>
Subject: RE: IO abstraction layer for files
Date: Sun, 14 Jul 2002 19:03:38 -0700
Organization: Covalent Technologies
Message-ID: <00b001c22ba3$d5c7a610$0a01230a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D321D1B.2000800@apache.org>
Importance: Normal

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.

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