You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@lnd.com> on 2000/07/27 01:12:02 UTC
Inquiry: Design meeting for Filtering by Requirements: ISAPI/NSAPI/APAPI
***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
Re: Inquiry: Design meeting for Filtering by
Requirements:ISAPI/NSAPI/APAPI
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > Well since Randy hit the list first, and Covalent's space is pretty
> > central to everyone but NC :( let's try that... I'm hearing dates
> > of Wed 8/9, Thurs 8/10, or Fri 8/11 ...
> >
> > If anyone interested in meeting on Filtering/Design resolution and
> > has a problem with those dates, shout. (Late in the week hurts me,
> > but not too horribly... I have to jump ORD to Cody WY first thing
> > Sun a.m.)
>
> Let's arrange to do this Friday. This way, if we can't finish it in one
> day, we have Saturday to finish the rest of it up. I know Dirk is not
> going to be available early Friday morning, but he should be back around
> noon, and I think Tony and I can cover his desires for filtering.
>
> Dirk also has NSAPI experience, so if nobody else shows up with it, when
> Dirk gets here, we are covered.
>
> Does anybody want to pipe up and say they are coming?
I'd love to say I'm coming, but I don't see how that can possibly happen
(especially since I'm on holiday starting Thursday). Waaah!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
RE: Inquiry: Design meeting for Filtering by Requirements:
ISAPI/NSAPI/APAPI
Posted by rb...@covalent.net.
> Well since Randy hit the list first, and Covalent's space is pretty
> central to everyone but NC :( let's try that... I'm hearing dates
> of Wed 8/9, Thurs 8/10, or Fri 8/11 ...
>
> If anyone interested in meeting on Filtering/Design resolution and
> has a problem with those dates, shout. (Late in the week hurts me,
> but not too horribly... I have to jump ORD to Cody WY first thing
> Sun a.m.)
Let's arrange to do this Friday. This way, if we can't finish it in one
day, we have Saturday to finish the rest of it up. I know Dirk is not
going to be available early Friday morning, but he should be back around
noon, and I think Tony and I can cover his desires for filtering.
Dirk also has NSAPI experience, so if nobody else shows up with it, when
Dirk gets here, we are covered.
Does anybody want to pipe up and say they are coming?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: Inquiry: Design meeting for Filtering by Requirements: ISAPI/NSAPI/APAPI
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Thursday, July 27, 2000 11:48 AM
> To: new-httpd@apache.org
> Subject: Re: Inquiry: Design meeting for Filtering by Requirements:
> ISAPI/NSAPI/APAPI
>
>
> I can offer IBM's facilities here in Raleigh. San Francisco
> probably works better for most
> folks though so that's okay too. Not sure of my schedule at
> the moment, but I think later
> in the week will work (Wednesday or later). Monday is
> definitely bad for me if I have to
> travel to CA.
>
> Bill
>
> > I'd be happy to offer the facilities at the Covalent office
> in San Francisco
> > to make this happen. It would be nice to see everyone here
> and a bay area
> > meeting should allow good participation.
> >
> > -Randy
Well since Randy hit the list first, and Covalent's space is pretty
central to everyone but NC :( let's try that... I'm hearing dates
of Wed 8/9, Thurs 8/10, or Fri 8/11 ...
If anyone interested in meeting on Filtering/Design resolution and
has a problem with those dates, shout. (Late in the week hurts me,
but not too horribly... I have to jump ORD to Cody WY first thing
Sun a.m.)
Bill
Re: Inquiry: Design meeting for Filtering by Requirements: ISAPI/NSAPI/APAPI
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
I can offer IBM's facilities here in Raleigh. San Francisco probably works better for most
folks though so that's okay too. Not sure of my schedule at the moment, but I think later
in the week will work (Wednesday or later). Monday is definitely bad for me if I have to
travel to CA.
Bill
> I'd be happy to offer the facilities at the Covalent office in San Francisco
> to make this happen. It would be nice to see everyone here and a bay area
> meeting should allow good participation.
>
> -Randy
>
> > -----Original Message-----
> > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > Sent: Wednesday, July 26, 2000 4:12 PM
> > To: new-httpd@apache.org
> > Subject: Inquiry: Design meeting for Filtering by Requirements:
> > ISAPI/NSAPI/APAPI
> >
> >
> >
> > ***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
> >
>
Begging for NSAPI folks... Design meeting for Filtering
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Just to reiterate...
If anyone on the list is an NSAPI guru (or at least plays one
on TV) please speak up, loudly :)
Bill
RE: Inquiry: Design meeting for Filtering by Requirements:
ISAPI/NSAPI/APAPI
Posted by Rasmus Lerdorf <ra...@apache.org>.
I can offer a conference room at Linuxcare (SEGA/Macromedia building at
8th & Townsend) as well if required.
And yeah, I'm game. I won't have all that much to offer, but I need to
understand the final design, so I probably should sit in.
-Rasmus
On Thu, 27 Jul 2000, Randy Terbush wrote:
> I'd be happy to offer the facilities at the Covalent office in San Francisco
> to make this happen. It would be nice to see everyone here and a bay area
> meeting should allow good participation.
>
> -Randy
>
> > -----Original Message-----
> > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > Sent: Wednesday, July 26, 2000 4:12 PM
> > To: new-httpd@apache.org
> > Subject: Inquiry: Design meeting for Filtering by Requirements:
> > ISAPI/NSAPI/APAPI
> >
> >
> >
> > ***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
> >
>
>
RE: Inquiry: Design meeting for Filtering by Requirements: ISAPI/NSAPI/APAPI
Posted by Randy Terbush <ra...@covalent.net>.
I'd be happy to offer the facilities at the Covalent office in San Francisco
to make this happen. It would be nice to see everyone here and a bay area
meeting should allow good participation.
-Randy
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> Sent: Wednesday, July 26, 2000 4:12 PM
> To: new-httpd@apache.org
> Subject: Inquiry: Design meeting for Filtering by Requirements:
> ISAPI/NSAPI/APAPI
>
>
>
> ***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
>