httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Mod_include design
Date Fri, 27 Oct 2000 19:10:11 GMT

> First off, when I started working on this it wasn't yet hacked into mod_include so
> we came to basically the same conclusion concurrently. 

No, it was always this design, it's just that it wasn't fully
implemented.  It took a total of five minutes to add the set-aside
logic.  It isn't perfect yet, but it does work 99% of the time.

> Second, I don't know where
> you are talking about memcpy's being done.

The comments in your initial message about copying the tag into a single

> > But there is no state to save.  I'll explain.  If we have a brigade that
> > resolves to:
> > 
> >   foobar <!-
> > 
> > then we want to split at < so that we have two brigades:
> > 
> > "foobar " and "<!-"
> > 
> > On the next call to the includes_filter, we just concat the two brigades,
> Where was the first brigade squirreled away until the second invocation of mod_include?
> Are you going to start checking for the STARTING_SEQUENCE from the beginning again,
> or are you going to pick up where you left off? If you will pick up where you left
> off (as my current code does) how do you know where to resume?

We should just check from the beginning.  We are talking about a few
characters.  It isn't worth it to avoid the four or five character

> Thank you for the specific example. This makes sense. I will work to rewrite
> the parser and processor as an integral part of the brigade processing. I can
> see the cases where just inserting on the fly would be appropriate. I would
> still assume that for cgi directives the leading buckets would be sent on
> since the processing could take a while. The cgi output would then be sent
> along as its own brigade later. Reasonable?

No, well yes, but the way this needs to be done, is that we need to pass
three brigades to all of the handle functions.  The first section, the
tag, and the end.  The handle_function then figures out what to send and
what to concat.

> > Plus, this really should be implemented as a real parser, not the current
> > hack we have.
> I'm assuming you aren't looking for a full YACC/LEXX implemented parser for
> this simple setup, just something cleaner and more formal than the kludged
> string matcher that is currently there.



Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message