httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject Inquiry: Design meeting for Filtering by Requirements: ISAPI/NSAPI/APAPI
Date Wed, 26 Jul 2000 23:12:02 GMT

***If you want to see filtering in Apache 2.0 (or can't stand
   the thought of filtering for 2.0) - PLEASE READ ON...

430 new-httpd messages titled *filter* since Feb 1, and growing :)

I was just reviewing the state of filters to implement mod_isapi
filtering/revision 5.0 support.  I hope to have a patch that
illustrates all the hooks and callbacks exposed in the ISAPI
model no later than Friday night, so we can really look at what
ISAPI filtering pseudo-compatibility demands.

I am also concerned that we look at what NSAPI support could
entail, especially in terms of filters.  That's not my hat...
Is anyone on the list strong in the NSAPI?

The crux of my personal interest:

  *) An ISAPI coder (or NSAPI) should be able to use those
     API's with the unavoidable perfomance hit and small
     sections of incompatibility they will incur, and get their
     code running on Apache.

  *) An ISAPI or NSAPI coder should be able to read those
     mod_xxapi.c sources and grok the underlying differences
     between the thunked API they know and Apache's underlying
     API.  That alone will bring 80% of the skill gap coding
     for Apache's API.

So mod_isapi just became my top issue :(  I've bounced off some
questions on the Ryan's design... and am comparing notes to
Greg's patches, and I'm rather lost...

I'll roll the code for the filtering callback structure for ISAPI,
and it would be great if someone would tackle the same for NSAPI.
But to get this into an October beta or rollout looks bleak.

QUESTION:  Who is game to sit down in a developer's cabal for a day 
and thrash out these details... The very short syllabus looks like:

  1) ISAPI and NSAPI existing compatibility requirements

  2) New filtered goals for existing Apache modules

  3) Filter configuration (httpd.conf) requirements

  4) Filter registration and calling conventions to implement 1 & 2

  5) Filter bucket handling for optimized (near zero or zero copy)
     multiple-filter invocations.

One thru three can be thrashed out in under 2 hours.  Item 4 & 5
are two to three hour debates working in the same room, or two to 
three week debates on the list.  I'm scared that we are defining
items 4 and 5 without everyone putting pen to paper on the first 
three, only to shoot ourselves in the foot.

I'm not suggesting the cabal would override the rules of the list,
and whatever is collected at the meeting would be posted back to the
list.  Patches are always subject to debate, vote and potential vetoes.

BOTTOM LINE: Who on the list has something to pipe in, and would be
willing to do a one-day meeting the week of, say, Aug 7th for one day.
Place and date TBD to accommodate as many as we can.  That gives us 
just _TEN_WEEKS_ to roll in filtering.  Which corporate advocate might
be willing to sponsor or lend the space?  My basement office and
conference center is a tad small for the likely suspects :)

I don't see it happening any other way... a little progress here, a little
progress there... and then what time is left to thrash it out for any
real world examples by ApacheCon?  Better reason, who wants to waste a BOF
session at ApacheCon still trying to thrash this out in October :?

Who's game?

Bill


Mime
View raw message