On Fri, Mar 02, 2001 at 06:25:56AM +1100, Luke Kenneth Casson Leighton wrote:
> > The issue here is, that the protocols, that are below SMB,
> > are more like sockets. From a clean point of view, they
> > should be implemented in the kernel, but none of us is
> > willing to write kerneldrivers for each OS out there.
>
> however, on NT, some functions already exist, such as CreateNamedPipe.
>
> and there is no way in hell i'm writing a kerneldriver for NT when there's
> a perfectly good function already out there.
Yah... that would just suck :-) Have no fear...
> however, i _am_ prepared to "mirror" that functionality in systems that
> _don't_ have a CreateNamedPipe function.
>
> so, the implementation of apr_nal_create_socket("namedpipe:foo", ...) on
> NT will call CreateNamedPipe. which i should imagine will be utterly
> trivial to do.
>
> and the implementation on non-NT systems will go through hoops and layers
> like there's no tomorrow [i.e. emulating what NT does in the kernel.
> *yuck* :)].
>
> if the buckets principle can hide this from a developer, so be it.
Yes, you could create a two types of buckets: one for NT using true named
pipes, and one for "those other guys" :-)
The appropriate bucket is inserted into the "input brigade" and the rest of
the input processing is blissfully ignorant. They simply read content from a
bucket.
------------------------
I'd also like to take a moment just to say that I'm describing what we
currently have. I'm not going to try to advocate or force particular choices
on you guys(!) It's your problem domain, and you know best. I'm just hoping
for a complete description of what we already have, so that you guys can
make an informed decision on the approach to take.
I certainly see no problem with an NAL type concept in APR itself (note that
buckets are "one step higher" in APRUTIL). Or possibly APR just grows more
types of sockets within its existing apr_socket_t public type. It is just
that we may have some other stuff that can help :-)
Pick your poison, and if the brigades and filters are not an appropriate
model for your data, then we can examine how to add an NAL concept to APR.
My personal, uninformed opinion :-) would tend towards adding new
OS-provided socket types to apr_socket_t (allowing all apps the benefit of
the new socket types; not just those that can fill in a func table), and
then building the "selection" mechanisms above that using buckets, brigades,
and filters.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
