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 [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
-----Original Message----- From: Ian Holsman [mailto:[EMAIL PROTECTED] Sent: Sunday, July 14, 2002 5:54 PM To: [email protected] 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
