On Wed, 2004-08-18 at 08:43, Robert Seeger wrote:
>
> ...
>
> Constraints:
> - Must be decoupled from the HTTP driver, so that that driver can be
> changed or replaced at any time without impacting any added drivers
I don't think my patch imposes a maintenance burden. It inserts the
following piece of code into the fastpath of the driver thread at the
end of driver.c:SockRead:
if (drvPtr->parseProc == NULL) {
return SockParse(connPtr);
}
i.e. if an alternative driver has not been registered, just carry on as
normal and parse the buffer of data expecting an HTTP request. This is
pretty trivial.
What follows it is a couple of lines of setup code which makes the
just-received buffer available to the Ns_ConnGets, Ns_ConnRead,
Ns_ConnReadLine, Ns_ConnContent etc. APIs.
The parseProc which implements the alternate protocol is then called.
Here's it's signature:
int (Ns_ParseProc) (void *arg, Ns_Conn *conn);
Pretty simple. This is the interface we're committing to support into
the future. I don't think I'm tying any body's hands here.
The first arg is just module specific callback data, the second a
pointer to the widely used Ns_Conn structure. That's not going away
anytime soon.
The return code can be one of: NS_SOCK_READY, NS_SOCK_MORE,
NS_SOCK_ERROR. Even if the internals of the driver thread were to
change radically, I don't think it would be too hard to continue
supporting this. Conversely, I don't think it would be too hard for
module writers to use an alternate API, considering it's small
footprint. Bigger changes have been made in the past.
And that's about it. The rest of the patch is trivial support code.
> Notes:
> - I'd like to see the Handler API be sufficient at the low level to
> allow an HTTP handler to be written that is every bit as efficient and
> speedy as what is being worked on for 4.1
Cut 'n paste the ~100 lines of code from SockParse which already
conforms to the Ns_ParseProc API and you're basically done.
> - I'd like to see the high level API be easy enough to use that one
> could register an "echo server" handler and write the code for it in a
> dozen lines or so
The example POP3 server, which is a simple, single-line oriented
protocol, implements an Ns_ParseProc in 24 line of code.
> - I'd like the progression from high level to low level be gradual, so
> the programmer can address only those issues that pertain to his
> specific protocol
A Tcl API could be wrapped around the Ns_ParseProc interface in the same
manner that ns_register_filter wraps Ns_RegisterFilter(). You would
have to make an interp available to the driver thread which doesn't
normally have one.
The Tcl code which implements your parser could call [ns_conn content]
and use the sls API to maintain state. Or you could wrap the
Ns_ConnReadLine etc. APIs.
Looks like an afternoons work.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
