httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@topsail.org>
Subject Re: Thoughts on a 2.0 API
Date Mon, 09 Jun 1997 23:45:44 GMT
Alexei Kosut wrote:
> 
> On Mon, 9 Jun 1997, sameer wrote:
> 
> >       I like the callback method of installing API hooks, as you
> > describe here. SOme of the phases you propose I think should be at a
> > different level, say 'connection-close' -- that should go on the
> > transport protocol API, not the request-processing API.
> >       I guess we need a list of the various types of APIs:
> >
> > - Transport protocol API (HTTP-NG module)
> > - Request processing API (Turning URL + req-headers into resp-headers + body)
> > - OS Abstraction API
> >
> >       I'm sure I'm missing stuff.
> 
> Well, a configuration API is a big one that we also need to work on.
> 
> I'm not so sure protocol and request processing should be
> distinct. There are a lot of benefits to putting them together. For
> example, one could write a version of mod_include that worked as a
> protocol extension rather than as a handler, that could be put as a
> "filter" over a request of any type (even CGIs). However, for this to
> work, it needs to be integrated with the request-processing API, so it
> can work with media types, be turned on and off at the right points in
> the request, etc... I envision HTTP-NG/SSL/etc... support as simply an
> extension of that. Especially if we need support HTTP-NG via a method
> that uses a technique involving a HTTP/1.x request with an "Upgrade:
> HTTP/2.0" header. Doing this with seperate protocol and request APIs
> is annoying. If they're integrated, it's a snap.
> 
> But I may be missing something.
> 
What about non-HTTP protocols? How would they fit into this abstraction
model?
-- 
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org

Mime
View raw message