apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: [RFC] Network Abstraction Layer - redux
Date Wed, 13 Jun 2001 12:06:14 GMT
the purpose of adding a NAL is to be able to farm out 
responsibility for dealing with other transports to
other programs, as proxies for those transports.

given that the filter code is designed to be in-memory,
the only way to achieve inter-process communication
is to use sh-mem, and that's a path i forsee as tricky,
at best.

it also ties in with the proposed apr_namedpipe_xxx() API.

that's _another_ type of communication / transport
that can be added to the list in the NALs.

do you _really_ want to write special filters to have to
deal with each and every single one of these transports?

if i can possibly explain this well enough, i think you
may agree that being able to bounce in-and-out of
separate programs at well-defined boundaries, with one
program being responsible for part of a message [a
header, for example], and treating the rest as opaque
data, makes a lot of sense.

TNG and NT are chock full of such things, and i _know_
that NT has a fully featured implementation of
bucket brigages / filters _and_ a NAL that is extensively
used to provide transport independence and processing of
LANMAN, IPC$, the whole lot.


> ----- Original Message -----
> From: <rbb@covalent.net>
> To: "Bill Stoddard" <bill@wstoddard.com>
> Cc: <striker@samba-tng.org>; <dev@apr.apache.org>; <lkcl@samba-tng.org>;
> <elrond@samba-tng.org>
> Sent: Tuesday, June 12, 2001 11:41 PM
> Subject: Re: [RFC] Network Abstraction Layer - redux
> >
> > I was under the impression that we had already decided, the last time this
> > thread surfaced, that all of this was possible with filters.  We can
> > redirect to different kinds of network primitives with a different "core"
> > filter.  The "core" filters don't even need to use sockets, they can store
> > their own communication medium in the conn_rec, and just use that.  The
> > only drawback, is that Apache will still require a single socket to
> > operate, but I am not sure that can't be worked around.  A REALLY QUICK
> > grep through the source has us referencing the client socket 28 times
> > directly from the conn_rec.  I am not convinced that some of those can't
> > just be moved to inside a filter.

> > > > Before I start throwing stuff at you, I'll introduce myself.
> > > > I'm Sander Striker, one of the Samba TNG team members. We have
> > > > been looking at the APR a bit to find out if we can use it in
> > > > our code.
> > > >
> > > > It looks all very promissing and that's why we want to contribute
> > > > some ideas to (from our point of view) improve the APR. The first
> > > > thing we are going to need is a higher level of abstraction for
> > > > the network layer. We have a complicated (to explain to outsiders)
> > > > protocol stack in which protocols can be called upon from several
> > > > layers.
> > > > Example:

View raw message