httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: PLEASE READ: Filter I/O
Date Fri, 23 Jun 2000 03:49:47 GMT
> From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> Sent: Thursday, June 22, 2000 10:43 PM
> 
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Thursday, June 22, 2000 10:29 PM
> > 
> > In the hook scheme, there are two options to the large 
> > database content issue:
> > 
> > 1) suck the whole thing into memory and return an ioblock pointing to it
> > 2) suck in a portion, return it in an ioblock, and return "call me again
> >    because I have more to give you."
> > 
> > I have labeled (2) as an "asynchronous style of programming."  The filter
> > management code needs to loop until the the filter stops  saying "call me
> > again." [ an alternative avoids the explicit loop in the filter management, 
> > but that creates similar/associated problems; see earlier posts for detail 
> > (or ask for detail here if the earlier post doesn't explain well enough) ]
> > 
> > To answer the question, we can toss (1) right out since we don't want 
> > a 100Mb working set for each request. That leaves option (2). This is
> > definitely possible, but it demands that filter writers implement an
> > async-style for the filter. The filter reads a chunk from the database, 
> > returns it in an ioblock, and returns "call me again". When the filter 
> > is called again, it reads the next chunk, returning it in an ioblock.
> 
> Ok... finally something I can bite into.  Have 80kb to 100mb html tables.  
> The 'html source' is static.  I have a filter layer that selectively parses
> html and returns subsets.  [Don't even start about how -bad- a coding style
> that would be... let's just use the example.]
> 
> A. How doesn't link based address this?  How do they compare?
> 
> B. Here's the kicker.  It's html... the end of block on
> 
> C. e is, whoops, there was the end of block one... entry B. is meaningless
>    to my html table parser, so I need to 'hold back' everything in entry B.
>    until I get to entry C, and then it makes sense and I can do something
>    with it.  How would the hook based, or the link based filter work this?

Real filter... read any .gif or .jpeg interlaced image... and return on the
first working subset (complete raster) until the total image remaining is
less than 8kb.  Images magically -pop- into focus, instead of banding.

A thousand other examples, all that need to know 'a little more' but could
chuck out (whoops, no chucks sometimes :) most of the current packet.

Mime
View raw message