[wp-hackers] Future Posting Fix Request

[Robert Deaton]

On 7/24/06, Doug Stewart <dstewart at atl.lmco.com> wrote:
> The advantage of not triggering this for everyday users is that we avoid
> the uncomfortable random long load times.  Force the "users" that are an
> actual burden on your site into doing something useful - firing your
> cron jobs and eating the load times so regular users don't have to.

Triggering it for everyday users isn't the problem. Where it works,
the system already essentially forks off a seperate worker process to
handle everything without any delay whatsoever to the end user.
However, under Apache as CGI, we need to find a different work around,
and all of those that come immediately to mind will cause the delays.

> Not suggesting this as a total replacement for any other solution, but
> it could offload quite a bit from other avenues.

Imho, the following things are wrong with some of the suggestions:
- The one about Akismet... Akismet is a plugin that relys on an
external service. I'd rather not have anything in the core rely on an
external service all the time. For example, even the reliance on
ping-o-matic as the default ping server was a bad thing when it was
taking 20-80 seconds for ping-o-matic to accept the pings.
-For search engine spiders, robots.txt, etc., or spammers, they are
simply too unreliable. A future scheduled cron even may very well be
triggered by any of them at any time, but we can't rely on only them
to do the pinging. Short of building some statistic analystics systems
in with the cron to detect whether or not another hit from a spammer
or search engine is likely to come within a short period of time after
the event is supposed to fire, there is no way for us to know which
sites can handle this kind of behavior or not.

-- 
--Robert Deaton