Feature Proposal: Plugin hooks to take advantage of Foswiki Stand Alone

Motivation

Foswiki Stand Alone architecture makes it possible to have persistent execution under FastCGI, ModPerl or as an HTTP stand alone server.

Currently initPlugin is called for every request, but some tasks need to be performed only once instead of for every request.

If we have other hooks corresponding to "onLoad" and "onFinish" called only once, we could have some performance improvements.

Description and Documentation

*Add once-called plugin hooks:

• • onLoad - called once when foswiki loads the plugin
  • onFinish - called once before foswiki terminates
• Deprecate the initPlugin (it's not a good name anymore, considering its semantics)
• Add per-request-called hooks:
  • initRequestHandler (in place of initPlugin)
  • endRequestHandler - for simmetry

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

-- Contributors: GilmarSantosJr - 15 Dec 2008

Discussion

EugenMayer, SvenDowideit and I talked about this on IRC today and we find a good idea to have it ASAP, since a lot of improvements are being made to extensions along with rebranding and we could take advantage of that to also have performance improvements.

So, I'd like to open an exception on the 14-day rule to commit this before xmas, so we'd get some more performance improvements on 1.0.0 release. (of course, given enough support from other developers)

-- GilmarSantosJr - 15 Dec 2008

I cannot oversee the impact of that proposed change at the moment, but since FSA is a central new feature in Foswiki 1.0.0 and given it would be useless without your proposed changes, I support the exception.

-- OliverKrueger - 15 Dec 2008

As far as I can interpret this proposal - it is touching the very heart of the execution of Foswiki and how extensions are run.

There is no way you guys can implement this, test it with at least 100 extensions in 4 days.

I have seen these requests before. Last time I said yes to something similar that someone promissed ready in two weeks, the project got delayed by 6 months.

Just a few weeks ago we agreed to release from trunk instead of Release branch to limit the overhead. The FSA code caused a lot of trouble that Sven and Crawford has been fixing and many extensions today cannot run without additional hacks like special sections in configure etc etc

It is extremely risky to take in this change. You think you have all covered now but the minute the rest of us start using our plugins we will run into trouble.

We do not even have the 14-day period to THINK about this change.

The purpose of 1.0.0 is not to save the world. It is to get Foswiki release out now.

My answer is a clear NO for 1.0.0.

If we do this we will have a Foswiki release end January earliest and that will harm this project significantly. We need a download available now so we go from a vapourware project to a software project.

After this we can launch a 1.1 soon after with this feature added, with extensions updated to take advantage of it so the end user actually feels a benefit from it.

No enduser will feel a benefit from a feature hardly any extensions is using yet. It is not urgent to get this feature out. The minute we have 1.0.0 out we can implement this feature in trunk and plugin developers can start converting their extensions. They do not need a release to be able to develop this feature.

-- KennethLavrsen - 15 Dec 2008 - 14:26

Now that 1.0.4 is out and we have trunk I change this to accepted. But trunk only.

-- KennethLavrsen - 25 Mar 2009

I clearly see the value of those handlers.

Maybe there are better names than onLoad and onFinish? How about initEngineHandler for symmetry. Not sure this would match the intended semantics. In any case the proposed new handlers should be ellaborated a bit more so that plugin authors can chose when to make use of these handlers. For instance, when exactly are those handlers called? Which internal objects are already constructed or are already gone? When does a BEGIN suffice?

For now, I make use of FSA by creating a global variable $doneInit inside the plugin that is undef on first load and set to true once the one-time init steps have been done. Sometimes I create a singleton $core object that stays active during all of the lifetime of the thread.

I do see the performance advantage in not having to call a bogus initPlugin that now has to check a global var if it needs to proceed or can bail out otherwise. Frankly, these kind of plugins might be quite rare and you only got one or two of that kind installed on your Foswiki, which infact will narrow the possible performance advantage.

There are also "normal" plugins that do heavy lifting initPlugin, e.g. reading topic preferences even though they might end up not needing them etc. I'd consider these plugins badly written and am pretty sure that they will stay that way even on the proposed new handler API. That's not only because these plugins aren't maintained anymore. This is just because it might get increasingly difficult to wrap around your mind how to write a plugin best. Don't misunderstand this as a concern against this proposal. I just wanted to point out how plugins look like right now and what the current best practices are to achieve a somewhat similar effect by making use of FSA.

-- MichaelDaum - 25 Mar 2009

What is the relationship of this feature request to AddFinishHandler? (and the associated Tasks.Item1328)

-- CrawfordCurrie - 25 Mar 2009

This proposal is important and should be pursued further!!!

Performance analyses show that plugin initialisation contributes a major amount of efforts during request processing even on an FSA setup. The original proposal specified an call-once onFinish handler this does overlap with the finish handler that we now have already. If we remove that one from the above list the remaining ones all make a lot of sense.

Thanks in advance.

-- MichaelDaum - 11 Aug 2009

Hi Michael,

This proposal is only part of the refactoring work to fully take advantage of FoswikiStandAlone architecture. Other parts:

• Identify which tasks are request-especifc and which can be shared among all requests
• Identify dependency relationships among the tasks
• Refactor core code/architecture to take advantage of persistent environments

The more general refactoring work should also cover VirtualHosting. I have a lot of interest on this, but not enough time available

-- GilmarSantosJr - 11 Aug 2009

Thanks for the update. I was afraid we've lost you on Foswiki

-- MichaelDaum - 11 Aug 2009

I've been busy for a while and I'm organizing myself to come back.

Kenneth: I'll raise separate proposals for those tasks that I listed before.

-- GilmarSantosJr - 11 Aug 2009

Hi Gilmar, Have you finished organizing yourself yet?

I'm going to mark this deferred to 2.0, so we can clean up the 1.2 release plan.

-- GeorgeClark - 02 Apr 2014

Changing to Parked. Needs a developer to adopt.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in