Ross Gardler wrote:
> Ron Blaschke wrote:
>> Ross Gardler wrote:
>> 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.
Good, so this shouldn't be too hard, either.
> Today is Forrest-Tuesday [1] you can find us on irc.freenod.org #for-oct
> if you need any pointers.
The one thing left that keeps me from getting started is that I don't
know how to contribute the plugin. I don't have any commit rights to
Forrest, so I guess I am limited to (1) create an issue and attach my
changes there, or (2) host the plugin myself. The names would be
org.apache.forrest.plugin.internal.cprofile or
org.rblasch.forrest.plugin.internal.cprofile, respectively.
Any thoughts?
>> 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.
I've tried adding the profile page as arg to ...cocoon.Main after
${project.start-uri} in main/targets/site.xml, and this seemed to
work. If by design or accident I don't know.
So it might actually be a good fit to enable profiling via a command
line option.
Ron
