httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Mod_include design
Date Thu, 02 Nov 2000 17:34:43 GMT
On Fri, Oct 27, 2000 at 12:10:11PM -0700, rbb@covalent.net wrote:
> Paul Reder wrote:
> > > 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.
> 
> Yes.

Paul -- yes, a clean parser is much more desirable. From your initial note,
I think you are definitely on the right track: a state machine to record
where you are in the parsing algorithm (and lexing if you separate that
out), and storing context into the filter context (at one point, Ryan said
something about a "static variable" -- I'll smack him for that next time I
see him (he broke headers because he held context that way); use the context
field like you intended).

I believe that you can probably update mod_include in several waves. In
fact, I would highly recommend this, so that the individual changes can be
reviewed. This also shows people progress, and keeps us from thinking "damn.
mod_include isn't going anywhere and needs to be fixed now". (I was berating
Ryan at the conference for breaking mod_include, then not fixing it; he
pointed out you were working on it, but that was news since I hadn't seen
anything (yet)).

What would be slick, and would help out your parsing work is to document the
grammar and put it into comments within mod_include. Once a rigorous grammar
is present, then it will be easier for us reviewers to check the work
against that grammar.

It seems that the discussion also mentioned handling of the tag and how it
might be split across buckets. The tag isn't going to be that long... memcpy
the darn thing into a holding buffer so you can do a strcmp(). I don't know
how long an individual directive may be, but it might be advantageous to
see if a maximum exists and copy directives into a holding buffer. NOTE:
this doesn't conflict with the "no copy" desires of buckets. The bucket of a
mod_include file is raw text rather than directives; that raw text won't get
copied (since you'd only copy to the buffer when a directive is seen). Using
a buffer for the tag/directives will simplify the context structure that you
posted: you'd only need a buffer for the directive that you're accumulating.
Any brigade contents from before the directive will have been passed. Any
brigade contents after a directive simply hasn't been parsed (yet) by the
mod_include filter and is still in a param/local variable on the execution
stack (cuz you won't return from the filter until you've completed parsing
through it; the only state for a return is "in a directive [and the
directive buffer is being filled]" or "outside a directive [and I'm not
holding anything in the directive buffer or a set-aside brigade]").
[ quick question: what *is* the max length? the grammar will help with that ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message