httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Mod_include design
Date Thu, 02 Nov 2000 19:20:59 GMT

> Ryan, a state machine is how parsers like this work, in our "here is some
> more text" model. It is required, but you can deny it all you like :-)

Greg, the problem is where the state machine goes.  I agree that there
will be _A_ state machine in mod_include.  I disagree that it should be
the state machine that Paul initially outlined.  The state machine that he
outlined was to determine how to split a tag out of the brigade.  This is
unnecessary.  By just splitting the brigade at any subset of <!-- and
-->, we can find the tag, and at that point we go into the state machine
to actually parse the tag.

> 1) not parsing a directive [pass all text up to a directive marker]
> 2) parsing a directive [accumulate until we have a complete directive]
> These two states will exist, but it is entirely reasonable/possible that it
> will not be concretely exposed as a two-state machine. The state could
> simply be "if anything is in the directive buffer, then we are in state 2;
> if the buffer is empty, then we are in state 1".

The state machine I am referring to, is the state that tries to find a
tag.  It is unnecessary to have a full-blown state machine that goes
across filter invocations, because we can't deal with the tag until we
have a full tag anyway, so saving the full state in the ctx pointer isn't

> [ note that "buffer" could be a set-aside brigade; if you don't memcpy a
>   directive out of a brigade into a buffer, then the parsing becomes much
>   more difficult, and more states would be desirable to control and drive
>   the parsing ]

I disagree that the copy is necessary, because the code is completely
localized to one or two functions, but that's fine.

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

View raw message