Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 13 Jun 2001 08:35:41 -0700 (PDT)
From: <rbb@covalent.net>
To: Bill Stoddard <bill@wstoddard.com>
Cc: <rbb@covalent.net>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
	<dev@apr.apache.org>
Subject: Re: [RFC] Network Abstraction Layer - redux
In-Reply-To: <005601c0f415$2b43fb60$bb431b09@sashimi>
Message-ID: <Pine.LNX.4.30.0106130833070.6340-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> > The problem I have with this code idea isn't that it isn't useful to
> > httpd.  It is that we have been down this road once, and the model wasn't
> > flexible enough.  What problem are we trying to solve that the filter
> > mechanism doesn't solve?  If the answer to that question is "filters are
> > in Apache, and we want this out of Apache", then move filters out of
> > Apache.
>
> No way man :-)

Why not?

> > If the answer is, "We need a better way to abstract the network
> > for x, y, and z", then cool let's do it.
>
> I would argue that we do not have a good (read architecturally clean) way to abstract
> network io with filters. The NAL is a perfect compliment to the filter code. Here are my
> specific itches:
>
> 1.  My SSL library API uses a different model than OpenSSL. Specifically, it uses uses
> secure_socket calls (e.g., secure_read(), secure_write(), etc.).  I -could- integrate SSL
> into Apache 2.0 using filters, but I would have to replace core_inout_filter and
> core_output_filter with my own filters, possibly implement special bucket types
> (apr_bucket_secure_socket_t, etc.)  With NAL, I can just hook the network io primitives
> with my own calls and use the filters already in Apache. I hope to use OpenSSL but that is
> just not a possibility now. My itch is real to me even if you don;t feel it :-)

I'm not saying your itch isn't real, I'm saying I disagree with how you
want to scratch it.  :-)

> 2. I gave a pitch about IBM's Fast Response Cache Accelerator (aka AFPA) at ApacheCon a
> few years back. The AFPA implementation on Windows uses it's own socket API (afpa_read,
> afpa_accept, afpa_send, et. al.).  Again, the NAL provides a clean way for my Apache
> module to hook the right NAL implementing my specific network io primitives with the
> minimum amount of shuffleing httpd code.
>
> Can I do both of these with filters? Sure, but the code architecturally ugly as sin.
> Allan Edwards solved both of these problems cleanly in early Apache 2.0 iterations using
> Dean Gaudet's IOLs. NAL is essentially a scaled back version of Dean's IOLs (NAL is
> focused just on network i/o, not filtering). And I know what Luke is talking about as
> well.  Windows NT does implement filters (AFPA uses file system filters) in addition to a
> network io abstraction layer.  NAL is a great compliment to filters.

I'm saying that the code doesn't need to be architecturally ugly.  The
problem, is that our core filters are big and do too much, IMNSHO.  Break
out the core filters to smaller chunks that are available to other
filters, and I believe this will solve your problem completely.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------