Post Processing

Jacob et al.,

Option 2 seems the most practical indeed - although option 1) would get a
vote for consistency I guess. Option 3 is too much work for too little gain.

BTW: has the doc-sprint happened and if so, what's the verdict?

Rgds,
Jeroen

> 
> --__--__--
> 
> Message: 3
> Date: Wed, 17 Dec 2003 22:26:40 -0500
> From: Jacob Smullyan <[email protected]>
> To: "Adam DePrince, CSA" <[email protected]>
> Cc: [email protected]
> Subject: Re: [Skunkweb-list] Post processing
> 
> 
> --y0ulUmNC+osPPQO6
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> After looking at it a bit during my train ride home, I think there are
> three ways to go, two of them minor variants of the same idea and both
> very easy to implement, the third a bit harder and very possibly not
> worth implementing.
> 
> The first idea is similar to what Adam proposed -- adding a hook that
> would contain filters that could modify the response.  However, if you
> have filters, you might want to have several acting in series, so you
> couldn't use the present Hook or KeyedHook's return value as a way of
> implementing that, as returning something stops the hook; you'd have
> to separate making and saving a modification of the response from
> stopping the hook.  That's easy -- just put the response temporarily
> in the session dictionary (session here in the requestHandler sense,
> not the sessionHandler sense). =20
> 
> If you are doing that, you have two options.  1) Rewrite web.protocol
> and templating.Handler a tad so that that is how the response is
> gotten out of HandleRequest in the first place.  (Currently,
> HandleRequest returns the response, but it could simply run and then
> the web service could look for the response in the sessionDict.)  The
> current hook functions in HandleRequest wouldn't return anything, but
> wouldn't do anything either if a response had already been deposited
> in the sessionDict.  If this were to be done, response filters could
> simply be appended to HandleRequest after templating's functions, and
> there would be no need to add any new hook anywhere.  However, this
> approach might break some code out there that I don't know about.  2)
> Leave HandleRequest alone, and add another hook to web.protocol just
> to process the response.  It would be empty by default.  The response
> would be put in the sessionDict before the hook and taken out
> afterwards.  This wouldn't break any code, and would probably be
> cleaner, although I feel conservative about adding hooks.  (Even an
> empty hook takes a little time each request to do its little bit of
> nothing for you.  Add a lot of nothing together, and you have too much
> of it.)  Also, I'm inclined to think that such a hook should be a
> Hook, not a KeyedHook, as what filters you use is probably largely
> independent of how you got a response to filter (you could always look
> at Configuration.job inside the hook function if you cared, in any
> case).
> 
> The third approach would be to implement some kind of subrequest or
> servlet chain/pipeline mechanism, which would probably require major
> rejiggering of how the request cycle currently works. =20
> 
> So, my inclination would be to add a ProcessRequest hook to
> web.protocol, to maintain backwards compatibility and just to keep
> filters conceptually separate from the initial generators of
> responses.  I've tested this, and if it will work for Adam and no one
> has any objections or ideas for something better, I'll check it in.
> 
> Speak now, or forever hold, etc.
> 
> js
> 
> 
> On Wed, Dec 17, 2003 at 05:27:17PM -0500, Jacob Smullyan wrote:
> > On Wed, Dec 17, 2003 at 11:12:45AM -0500, Adam DePrince, CSA wrote:
> > > 
> =20
> > >=20
> > > My motivation was my own itch.  I needed created a way of 
> removing \n's
> > > from the html generated by skunkweb.  Instead of using 
> spool I figured
> > > that in one effort I would:
> > >=20
> > > 1. Document and provide a "how to" example on writing a service=20
> > > 2. To do #1 I wanted to provide something useful, but 
> simple to write,
> > > like an outgoing filtering module.
> > >=20
> > > I'm hoping that 
> skunkweb-3.5b5.template-postprocess-hook.patch would be
> > > accepted into the skunk sources. =20
> >=20
> > I'm definitely agree that post-processing should be easier to do.
> > What you've done seems very straightforward.  But it has 
> one drawback
> > -- it only applies the filter to content that emerges from that
> > particular handler.  I'd prefer the filter functionality to be more
> > general.   I'm in a rush right now, but I'll write more about it
> > later.  In the meantime, if anyone wants to sound off on 
> the topic of
> > filters, subrequests, or what have you, this is your opportunity....
> >=20
> > j
> 
> 
> 
> --y0ulUmNC+osPPQO6
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/4R5wuqamFyFXXLIRAgdVAJ9L+zO567TzbiJqfWzXMVJ507ealwCcD36g
> dmTIDyj/izyIl7X6GhLtmiE=
> =JYn1
> -----END PGP SIGNATURE-----
> 
> --y0ulUmNC+osPPQO6--
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Skunkweb-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/skunkweb-list
> 
> 
> End of Skunkweb-list Digest
> 


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click