httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <>
Subject Re: Mod_include design
Date Wed, 25 Oct 2000 14:54:01 GMT

I think we are pretty much on the same page. I agree that mod_include can be
cleaned up and optimized. I just hadn't picked that up in the passing messages
as being one of the immediate goals. Please see the rest of my embedded comments. wrote:
> > Basically, as I understand it, mod_include needs to be fixed to handle SSI
> > tags that can span multiple buckets or, in worst case, multiple brigades.
> > The rest of the SSI processing (once the tag is obtained) seems to be ok.
> > In order to do this I am converting mod_include to be a state machine with
> > the state stored in the attached data structure in the filter ctx.
> No, the goal for mod_include is to re-write it to make it work much better
> than it did in 1.3.  Mod_include is a mess, and that includes all of the
> tag handling.  We don't need to worry about multiple brigades, because
> simply setting the tags aside and concat'ing the two brigade together will
> suffice for a tag that spans brigades.  All we need is something that
> allows a tag to span buckets, and the logic to set-aside the partial
> brigades.

As far as I can tell this is just a restatement of what I said. A tag can span
brigades. The pertinent bytes from the first brigade need to be split and set
aside so that they can be concat'ed to the following brigade so that the matching
and processing can continue. If I am incorrect please help me understand.

> >
> > Buckets are parsed until the STARTING_SEQUENCE (or at least the first byte(s))
> > are found. Once the STARTING_SEQUENCE is found, buckets are set aside into
> > the ssi_brigade in ctx until the ENDING_SEQUENCE is found. The bucket containing
> > the first byte of the STARTING_SEQUENCE is split at the first byte. All buckets
> > up to the new split bucket are passed on.
> >
> > If a partial STARTING_SEQUENCE is found at the end of a bucket, that bucket is split
> > and set aside. If the bytes in the next bucket do not continue to match the
> > STARTING_SEQUENCE the state machine is reset. The set aside buckets will be passed
> What are you storing in the state machine?  If you are storing the
> state of the starting or ending sequence, can't this be done without
> storing the state in the ctx pointer.  I would rather see that work as a
> static variable, much in the way it currently works.  The only thing that
> would need to be added, is the logic to split a bucket at the beginning of
> the tag, even if the full tag isn't in this bucket.

It is my understanding that mod_include is invoked fresh for each brigade.
It is also my understanding that the appropriate place to store away persistent
information across invocations (stuff that would ordinarily be static or
global) is in the ctx. If the ctx is not for this purpose then what purpose
does it serve?

The information stored in the state machine was described in the comments for
the data structure that is being used (attached to the end of my post). Is there
something related to the comments about which you have a question?

> > >From here on, processing of the SSI tag proceeds as before.
> I really dislike this statement.  The whole point of this was to try to
> clean all of this up, not to hack something new into place.

As I stated at the top of my note, my perspective was just my current 
understanding and I was looking for feedback. I am perfectly happy to work
on rewriting the tag processing as well. I think I would prefer to handle that
as a second phase of optimization after the bucketized code is working and
committed. That way, everyone has a working include filter while the rest of
the work is happening.

> I would like to see mod_include re-written, so that the handle_foo
> functions actually return a brigade and that brigade is inserted into the
> original brigade in place of the original tag.

I guess my high level design was too high. My rewrite, as it stands now, pulls the
buckets related to the tag out of their brigades (passing along the brigades
that precede the tag, splitting the final bucket at the tag) then creates a new
brigade containing the content generated by the tag processing. The new brigade
is not inserted into the original brigade since that brigade has already been
passed on. The new brigade is passed along as a separate brigade.

> > I'm sorry this has taken me so long, but I have been out of the 2.0 loop for
> > a while and have had a lot to learn with all of the brigade and filter
> > code. I have been picking up steam over the past couple of days and hope to
> > have something working in the next couple of days. It would be very helpful if
> > I were allowed to finish this without dribs and drabs of patches to get this
> > piece or that piece fixed in the current version, it just means I need to manually
> > merge the parts of these patches that still apply into the rewritten code to keep
> > them in synch.
> I was asked to make mod_include work this week, because we want to try to
> get 2.0 running on locus.  That requires that we be able to at least serve
> SSI pages.  This doesn't affect you negatively at all, because all of
> these hacks that I am adding should be taken care of by your own
> code.  Just copy mod_include off to the side before you do an update, then
> copy it back afterwards.

Sorry, I was just feeling a little tense. I'm trying to work as fast as I can, but
feel like there isn't room for a new guy to learn the ropes. I realize that there
is a lot of desire to get this to come together soon. But I also feel that if you
want help from more than just the current core of coders that new guys need time to
learn all of the changes that have occurred. I know 1.3 pretty well, but haven't had
time to keep up with all of the 2.0 changes. I'm using mod_include to learn so that
I can contribute more in the future. It will take me longer than you to get this together.

Paul J. Reder
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

View raw message