Remember to post from Organic next time cliff...
Brian
---------- Forwarded message ----------
Received: from lazlo.steam.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id MAA14755; Sat, 8 Jul 1995 12:24:56 -0700
Received: (from cliffs@localhost) by lazlo.steam.com (8.6.12/8.6.12) id MAA05162; Sat, 8 Jul 1995 12:33:00 -0700
Message-Id: <199507081933.MAA05162@lazlo.steam.com>
From: cliffs@steam.com (Cliff Skolnick)
Date: Sat, 8 Jul 1995 12:33:00 PST
In-Reply-To: rst@ai.mit.edu (Robert S. Thau)
"Re: it's late...but here is an idea" (Jul 8, 11:26am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: rst@ai.mit.edu (Robert S. Thau)
Subject: Re: it's late...but here is an idea
Cc: new-httpd@hyperreal.com
On Jul 8, 11:26am, Robert S. Thau wrote:
} As a first note, the cost of the scheme above really is a bit high.
} As near as I can tell, the server more or less has to fork so that
} your "handler 1" and "handler 2" run in separate execution contexts,
} and fork() is something that I at least am trying to get away from.
} ("handler 1" and "handler 2" will generally deadlock if they are run
} in the same process, and are processing a document of nontrivial size
} --- "handler 1" writes enough to fill the pipe and then blocks,
} guaranteeing that "handler 2" will never be run to read it back out).
True, but still less than the cost of a CGI.
} I had been thinking about giving modules some kind of access to SSI,
} which is at least one of the things your scheme would accomplish, but
} along very different lines --- basically, of keeping the current SSI
} includes module as a framework, but giving *it* an API which would
} allow other modules to register their own SSI directives. This avoids
} the difficulties involved in trying to somehow stack response
} handlers, and just as importantly, it guarantees users some basic
} consistency in the syntax of new directives, or at least in the ways
} those new directives are set off from the enclosing text (which might
} otherwise be all over the map).
OK, I see what you are saying here. In Fact, I agree that this would
be a better solution and easier to get running. I hope the restriction
on format is only a small one, I would like to really add any tag. [.Note
not that I support adding those tags, but I feel that the mechanism should
be very general.]
} In closing, my general feeling is that if you want to ship soon, then
} it's too late to get something like this into the first release --- it
} has to be designed right, or it will come back to haunt us.
Should have #ifdef FUTURE'd my email :) I like your thoughts better
than my original one, I'll retract my suggestion.
Cliff
Brian
---------- Forwarded message ----------
Received: from lazlo.steam.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id MAA14755; Sat, 8 Jul 1995 12:24:56 -0700
Received: (from cliffs@localhost) by lazlo.steam.com (8.6.12/8.6.12) id MAA05162; Sat, 8 Jul 1995 12:33:00 -0700
Message-Id: <199507081933.MAA05162@lazlo.steam.com>
From: cliffs@steam.com (Cliff Skolnick)
Date: Sat, 8 Jul 1995 12:33:00 PST
In-Reply-To: rst@ai.mit.edu (Robert S. Thau)
"Re: it's late...but here is an idea" (Jul 8, 11:26am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: rst@ai.mit.edu (Robert S. Thau)
Subject: Re: it's late...but here is an idea
Cc: new-httpd@hyperreal.com
On Jul 8, 11:26am, Robert S. Thau wrote:
} As a first note, the cost of the scheme above really is a bit high.
} As near as I can tell, the server more or less has to fork so that
} your "handler 1" and "handler 2" run in separate execution contexts,
} and fork() is something that I at least am trying to get away from.
} ("handler 1" and "handler 2" will generally deadlock if they are run
} in the same process, and are processing a document of nontrivial size
} --- "handler 1" writes enough to fill the pipe and then blocks,
} guaranteeing that "handler 2" will never be run to read it back out).
True, but still less than the cost of a CGI.
} I had been thinking about giving modules some kind of access to SSI,
} which is at least one of the things your scheme would accomplish, but
} along very different lines --- basically, of keeping the current SSI
} includes module as a framework, but giving *it* an API which would
} allow other modules to register their own SSI directives. This avoids
} the difficulties involved in trying to somehow stack response
} handlers, and just as importantly, it guarantees users some basic
} consistency in the syntax of new directives, or at least in the ways
} those new directives are set off from the enclosing text (which might
} otherwise be all over the map).
OK, I see what you are saying here. In Fact, I agree that this would
be a better solution and easier to get running. I hope the restriction
on format is only a small one, I would like to really add any tag. [.Note
not that I support adding those tags, but I feel that the mechanism should
be very general.]
} In closing, my general feeling is that if you want to ship soon, then
} it's too late to get something like this into the first release --- it
} has to be designed right, or it will come back to haunt us.
Should have #ifdef FUTURE'd my email :) I like your thoughts better
than my original one, I'll retract my suggestion.
Cliff