| October 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
| Sep Nov | ||||||
This site is no longer maintained.
My current weblog.
The other day Ian Hickson dropped by and added a comment to my post calling for a Pingback Retrieval API. My response is that the Radio community loved Pingback, but I still don't see any implementations for Radio users.
Having a Pingback Retrieval API, and encouraging the creation of stand-alone Pingback servers supporting that API, would accomplish several things:
- Random CMS can integrate with Random Pingback server. The end-user is empowered to choose whichever Pingback server best suits their environment (Perl, ASP, Cobol).
- Provides a clear path for certain classes of CMS, especially client-based tools like Radio, to integrate Pingback. The CMS folks can focus on integrating pings with the CMS instead of having to re-invent the wheel by creating yet another Pingback server.
- Third-parties would be able to provide Pingback services to end-users.
The Pingback Retrieval API doesn't require many methods: Register, List, and Clear would be enough. Everything else is an implementation detail that can be left to the developer. Better implementations might provide a web interface for managing pings and offer additional services, like ping-forwarding via email/RSS/Trackback.
If you build it, they will come...
I'll put my money where my mouth is: Add a Pingback Retrieval API to the official spec and I will commit to building a reference implementation and hosting it until such time as it can no longer be supported by my web host.