httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: Mod_include design
Date Thu, 02 Nov 2000 18:48:52 GMT
The changes I had to make to get mod_cgissi.c working were really quite
minimal, the biggest being handling a tag spanning across a buffer. The main
work was to maintain state (2 states, in tag and not in tag), and some futzing
with GET_CHAR to work with a buffer rather than a file and indices into that
buffer. You could probably do something very similar with buckets rather than
buffers. In fact, you could probably extend my work to use buckets, not that
this is the best solution...

Bill
----- Original Message -----
From: <rbb@covalent.net>
To: <new-httpd@apache.org>
Sent: Thursday, November 02, 2000 2:20 PM
Subject: Re: Mod_include design


>
> > 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
> required.
>
> > [ 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
>
______________________________________________________________________________
_
> Ryan Bloom                        rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> ----------------------------------------------------------------------------
---
>


Mime
View raw message