forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Faciliatating profile use (Re: Fixing a Howto)
Date Tue, 04 Oct 2005 15:08:08 GMT
Ron Blaschke wrote:
> Ross Gardler wrote:
>>David, I am afraid to say I have not checked this out yet. Despite
>>noting its existence and the effort you put into this (and the docs).
>>Can I make a suggestion? (I'll do this the first time I find the need to
>>use this if it hasn't been done before me):
>>If we make an internal plugin of the profiler we can replace the 
>>necessary pipelines in that plugin. Then, to enable profiling all we 
>>need to do is add the plugin to
> I am about to start working on a plugin.  Actually, I thought I
> could start last weekend, but didn't quite make it.
> Most things are straightforward.  I'm only puzzled by the mix of input
> plugin (ie, take data from the profiler data store and render it) and
> internal plugin (ie, profile stuff and store results in profiler data
> store).  Can a plugin be both, input and internal?

An internal plugin sitemap gets mounted before anything else is done. So 
you can indeed make an internal plugin be both input and output as well 
as internal. It is easy to break everything with internal plugins, much 
harder with input and output plugins.

Today is Forrest-Tuesday [1] you can find us on #for-oct 
if you need any pointers.

 > Second, the profiler result page must be rendered last, or it wouldn't
 > contain all profile results.  Don't know how to do this, yet.

Hmmm... that's an interesting one. I don't think we can make the CLI 
process pages in a particular order, although I may be wrong.

If we can't do that then we could add Anteater or WebTest to the block 
and have some standard profiling scripts.



View raw message