[wp-hackers] Questions on execute-pings.php...

[Angsuman Chakraborty]

> Now some other folks have had their fingers in the code and I don't
know what it's doing.

At this point it is simply calling the execute-pings in a convoluted (network error prone) and slower way without any visible benefits (unless you are relying on 0.1 timeout of socket connection to kick in and fail the process occasionally). Additionally the spawn method (which isn't really spawning anything) is also called from admin interface in the footer. It simply looks like a worse solution as it stands today.

Also there is the question as to why it is not checking for post_date before issuing pingbacks and trackbacks. Pingbacks cannot be verified until the blog is actually published and visible on site. 

I would think a better a flexible solution would be to plug pingback, trackback, enclosure and pings to publish_post action event. The code requires some refactoring.

Thoughts?

Best,
Angsuman

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com]On Behalf Of Andy
Skelton
Sent: Tuesday, April 25, 2006 5:29 AM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Questions on execute-pings.php...
Importance: Low


On 4/24/06, David Chait <davebytes at comcast.net> wrote:
> I would assume/presume the person who added that code had done testing --
> and maybe had copied the approach from another project, not just making it
> up. ;)

No, I made it up.

Actually somebody had the bright idea of an iframe so that the browser
would be the middleman. This worked much of the time but failed when
the browser's next page wasn't an admin page, as can happen when
publishing from other tools than the usual Write Post screen, or
posting via XMLRPC.

My solution to that was to spawn the new thread via HTTP request from
the server itself. (Thus was born Argyle.) Now a post from an XMLRPC
client would spawn the pinger without relying on the user to visit the
dashboard, triggering the pinger via iframe. This worked on almost all
server configs. Certain CGI setups didn't work this way due to a PHP
bug so we forked the code for them: if CGI, use iframe instead of
HTTP.

This was all done in the interest of reducing the apparent delay when
posting, which was caused by waiting for so many remote servers to
respond to the pings.

Now some other folks have had their fingers in the code and I don't
know what it's doing. I hope the history lesson has some value anyway.
:-)

Andy
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers