New asisaid Features

I've added some new stuff tonight. Now, you can use any of the smilies supported by WordPress on my blog (I shamelessly borrowed the graphics and related material out of WordPress so that SAFARI could do this ). I borrowed JavaScript code from Alex King's wp_grins so that you can simply click the smilies of your choice below the comment box.

You'll also notice a new “others said here” section on the side (to be distinguished from the old “others said” section that is now known as “others said elsewhere”). The two links there will take you to a “forum view” that shows the blog posts that have the most comments and the most recently commented blog posts. The latter differs from typical “recent comments” sections on blogs in that it does not list every new comment individually, but instead shows the posts that have been commented on, rather like the way phpBB shows topics that have new replies. This insures that one busy post won't hide activity on less busy posts; this is not usually a problem, but keep in mind I'm designing SAFARI to work on bigger things than asisaid. The inspiration of using a forum view for this comes from Kevin's blog from long ago that was based on phpBB — I always liked that concept.

Give the new features a whirl and let me know what you think.

Pardon the Coming Dust

Awhile back, I made the decision to retain the UNIX time stamp system of dating within SAFARI, which I had started using when I first created SAFARI to be used without a database. The UNIX time stamp (seconds from the UNIX epoch of January 1, 1970) is easy to process in Perl, which makes it attractive to work with.

Big problem: this means more of the date processing must be done after a given piece of information is fetched from the db. If I was using the MySQL date-time field format (2005-03-13 16:12:30), I could do some processing within the SQL queries and therefore streamline things. Therefore, I'm going to undertake switching SAFARI over to this, right now. Unfortunately, SAFARI's sandbox that I built shares the database with the live asisaid copy of SAFARI, so while the code changes won't go into effect over here until I have things working, some things might behave oddly.

Update (2005-Mar-13 18:50): All done. Now on to fixing things to use my time zone (central) rather than UTC.

Update 2 (2005-Mar-13 19:45): The time zone is now appropriate too. That was a bit more difficult. As it turned out, I had accidentally set my code to store posting dates in Eastern Time (well, or more properly, to use the server's localtime(), which I have set to Eastern for the sake of matching other U.S. servers, despite the fact that it is in the Central time zone). So all posts from the old program were in UTC/GMT, but all after around noon on December 24, 2004 were in EST. Therefore, I put together this little SQL query:

SELECT cid,FROM_UNIXTIME(UNIX_TIMESTAMP(gmt)+18000) FROM uninet_comments WHERE ('2004-12-24 12:00' <= gmt)

Afterwards, I exported the resulting output and did some regex magic to turn the insert statements into update statements:

s/INSERT INTO `uninet_comments` VALUES ((.*?), '(.*?)');/UPDATE uninet_comments SET gmt='$2' where cid='$1';/sgi;

Finally, I took the those SQL commands, fed them to MySQL. Rinse and repeat for the articles table.

After that, it was a simple matter to add the new time zone adjustments within SAFARI to take the GMT time information and convert it to Central Standard Time (UTC-6:00). Now, I just need to figure out how to implement daylight savings time support, so that posts and comments posted during DST will be UTC-5:00 without making standard time posts and comments switch as well.

Request for Comments: Pingback NG

Trackback
Trackback is older than Pingback and is dominant primarily because it was advocated by Six Apart (MovableType). Now, with the winds blowing in WordPress' favor (at least from what I can see), I wonder if Trackback will eventually be marginalized, since Pingback is automatic in WordPress, whereas Trackback is not.

The flaws in Trackback, in my opinion, are as follows: (1) the pinging process uses the HTTP POST form data mechanism rather than XML-RPC and (2) there is no notification of what form the link takes on the site initiating the trackback. The first is a flaw that seems to be caused by a desire for simplicity. To send a form via Perl using Trackback, all we need to do is call LWP::UserAgent and feed it the form item names and contents. Easy, but not that much easier than feeding a properly formed XML-RPC document to LWP::UserAgent using the same POST method. This creates a situation where we send information in one format (URI Encoded form data) and receive a response in a different format (XML). The second flaw probably wasn't obvious when the spec was originally created, but is now clear; since I know what entry is being linked to but not the actual URL leading to that entry, my blogware must scan the initiating site's page for every possible format my URL might be in, if I wish to verify that linkage has taken place. Adding another parameter to the trackback spec (it could be optional for backwards compatibility) that contained the form of the link that the initiating blog was asserting it was using, would allow for an easy rectification of this issue.

Pingback
Pingback's problems are bit more annoying than what I have listed above. First, since the only two parameters of the spec are the initiating blog entry's URL and the destination URL (which, does, at least, solve my second complaint concerning Trackback), we are confronted with a big problem on a dynamic web site. The pingback client might tell me that http://site/blog/entry/22 is being linked to, but if I support multiple URL formats to request a given document (either directly via the blogware or indirectly via mod_rewrite), I must perform pattern matching to figure out exactly what http://site/blog/entry/22 links to. This isn't a problem in cases where the pages are static, such as some of those that Pingback seeks to support, but it is the problem in the case of blogware. This is not a problem with Trackback, since the trackback server can be different for each page (thereby identifying which document is being linked to), but it does rear its ugly head with Pingback, since the goal is to have one Pingback server for all documents on the site.

Therefore, I would propose that an additional, optional attribute should be added: Pingback-ID. This would be a text string that could be in any form and could be provided in the HTTP headers, just as X-Pingback supplies the pingback server location. A pingback enabled site could push this additional X-Pingback-ID header just as easily as the primary Pingback header, and it could specify, in the form of the server's own choosing, how to properly identify the page. The form of the string could be the local path to the document, an article ID number or perhaps even something encrypted so that the server could insure that it received an unmodified copy when the string is sent back. Even in the case of pingbacks to static documents, the server could pass along a Pingback-ID to insure that the real file being linked to is easily identifiable, should its actual location be obscured by mod_rewrite, for instance. The format would not need to be specified in the Pingback spec, since only the server needs to understand what the string means. Once the client pulled in this information, the resulting XML-RPC ping could contain this parameter in addition to the standard parameters of the pingback.

The second flaw I see in Pingback is that it does not include any useful information about the initiating site. Optional parameters ought to include title/site name and a text excerpt/description, in the same manner as a Trackback. Without this, the Pingback server must go and attempt to pick out useful substitute information from the initiating site if we want to include pingbacks with trackbacks in the comments section of a blog (as WordPress does and I have also done in SAFARI). While this works, it can produce less useful results than if we are fed the proper information by the author of the source document. By making this optional, we would avoid making the Pingback spec any more specifically tied to blogs than it already is, while greatly enhancing its ability to be a suitable mechanism for blog-to-blog communication.

Conclusion
Pingback's flaws, in my estimation, make it harder to implement in a manner that provides the Trackback-like functionality it is being used for in WordPress and other blogware, and frankly, limits its usefulness even in broader deployments, due to problems such as the aforementioned inability to easily determine what the destination URL links to on a server that uses mod_rewrite or otherwise is non-static.

That said, Pingback is consistent in its usage of XML-RPC, and therefore is preferable, in my estimation, to Trackback in the future. An improved, Next Generation Pingback spec (or “Pingback NG,” for short) could easily remove the most problematic parts of the system, creating a spec that was simple and efficient to implement in blogware, like Trackback, while remaining more flexible than Trackback in where it can be applied.

Useful links:

• Pingback 1.0 Spec
• Trackback 1.1 Spec

Another Favor

I believe I have pingback and trackback fully implemented (both the client and server). Both work against my test implementations of themselves, as well as against my test WordPress installation. That said, testing on the same server doesn't provide all the variables that could be involved. Thus, I am asking anyone who would be willing to please pingback or trackback against this entry — especially if you use MovableType (but even if you don't!). Five juicy asisaid points are yours for the taking if you do so, just for making me feel better about my code.

Note: I have it setup so that it only accepts one trackback/pingback from a given entry, so if you try to do both a pingback and a trackback, you'll find it only accepts whichever one is sent first. Also, I have everything in place for automatic detection of both types of pings, however, if your blogware needs to be manually fed a Trackback URL, you'll find one on the permalink'ed version of this page.

Thanks for your help! And thanks, once again, to Christopher, Josiah and Eduardo for their volunteering on my last call for help. Without the help of you three, I may not have gotten this far so soon.

More Code Debugging

http://whatintarnation.net/blog/archives/2005/01/06/blast-from-the-past-ii-my-first-field-trip/ For debug purposes, please ignore.

CNet on Pingback/Trackback.

more testing

Could I Ask a Favor?

I'm trying to finish my pingback/trackback client implementation for SAFARI. I set up a copy of WordPress to use as a test target, but it isn't working right (my WordPress installation can't seem to locate the test entries I posted on it). Would any asisaid reader using WordPress be willing to allow me to send some test pings/trackbacks to an old blog pos on your site? It would be a lot easier if I was testing against a WP installation that I knew was in working order.

Thanks in advance! I'll provide extra asisaid points — how about 30? — for willing victi… volunteers.

Trackback and Pingback

Here's a question for my readers. Does your blogware do pingbacks, trackbacks or both? I'm trying to decide how to implement such things in SAFARI. It looks like trackback auto-discovery is fairly clunky, and, if I understand Six Apart's design of the same, it merely looks for an XML/RDF tag embedded inside the page — something I believe would not work on, for example, What in Tarnation!?!?!?!, which, to the best of my knowledge, seems to be lacking any XML/RDF information embedded on the article pages.

To continue to examine Christopher's blog (hope you don't mind, Christopher), I do see that he has a properly implemented < link > tag for Pingback auto-discovery on his site. Given this, I suppose SAFARI could automatically pingback every link mentioned in a post, but only trackback if explicitly told to. Of course, the other question is whether I should pingback to sites I also trackback. My dear reader, how does your blogware work on this matter?

Color me confused and boggled about this element of blogware implementation.

Update: OK, so Christopher's blog does have RDF encoded on the front page. But I haven't figured out how to properly find that if I link to a permalink rather than the front page. And that still leaves the question of whether I should pingback and trackback the same link. So, your insight is still much appreciated.

Update 2: It helps to examine more than one blog. As it turns out, Pressed and Ed both have proper embedded RDF information on the article pages. Kevin does not, but then again, I don't think his blog supports trackbacks now that he's moved off of WordPress.

So Christopher, straiten up and get trackback RDF information embedded in your article pages — it's the WITty thing to do. And, no, don't bother looking in my blog's HTML, I haven't implemented trackbacks yet.

Leave comments about how pingbacks and trackbacks work for your blogware below… I'll be very grateful for your help.

Welcome to the Other Side

Welcome to SAFARI 2, codename “Alexandra.” The more I use SAFARI 2, the more convinced I become it is really still alpha quality rather than beta. Here is what is still broken, ordered in two lists, one that contains “soon to be fixed” stuff and one that contains later stuff.

Soon

• RSS will return in the next few days.
• Lingering display problems will be corrected.
• Blogroll will return ASAP.
• Topics will work again.
• Problems in admin panel will be fixed.
• “Remember Me” cookie for comment will function.
• Friendly URL's will return (in backwards compatible way, no need to change your links to any post on asisaid, it will work again ASAP).
• Posting a comment pages will retain look of asisaid.

Later

• Proper rendering of trackbacks.
• Trackback support.
• Pinging of Weblogs.com/Blogrolling.com.
• Tons of other stuff.

If you see problems on these pages, please let me know in the comments below so that I can try to put it on the list of things to fix.

This will likely be my last post before Christmas, so have a very merry one. Blessings to you on the day of the celebration of Christ's birth. “Immanuel Hath Come to thee, O Israel”!

Progress as Promised

It looks like my new blogging software might be able to be unveiled later tonight or, at worst, on December 26. At least that's how I'm thinking at the moment. Right now, there are a number of key things missing, such as listing the proper number of comments on the front page, but that's more of a cosmetic issue than a serious issue that should be a showstopper. It's still better than no blog, right?

By the way, I want to give a really big “thank-you” to Christopher for offering WIT as a “home away from home” that I could post at temporarily. While I don't think I'll need it, given the progress I've made, it was nice just knowing I'd have a place to go, need be.

I wasn't sure how successful transfering the data from a flat file (plain text) database to MySQL would be, but it worked after spending a few hours hacking together a script to do so. The rest can come later, I figure. The big remaining job is to copy SAFARI 2 over onto the asisaid domain — right now I have it on a test domain and I'd like to keep that domain a test domain so that I can continue to work on progress to a “gold” 2.0 version of SAFARI without breaking asisaid (right now, I'd consider SAFARI 2 somewhere between late alpha and early beta stage — it works, but it still has some problems).

Anyway, just thought I'd give an update. I don't think I'll be done in time to do the Christmas post I wanted to do, but I'll just do it in a belated fashion. The other, really good news that I didn't have time to discuss yesterday is that the hospital released my dad yesterday. On Wednesday, he had sung “I'll Be Home for Christmas” to my mother — I'm glad he wasn't disappointed. The doctor seemed quite optimistic about the way things are going.

comments (on OfB)

St. Paul's Newsletter and Content Management

For that purpose, I wrote a simple CMS (Content Management System) during March and April of 2000 (that was time consuming, it's one of the only things I remember vividly from those months). Not having any practice at such it took a long time to figure out how to write the system. In fact, other than Slashcode, I was unaware that Free Software CMSes even existed. Never having used one previous, SAFARI (Standardized Automated Format And Retrieval Interface) is a bit different than other CMSes — in fact, in many ways, it doesn't really even resemble other CMSes. For example, at the moment, SAFARI is what I term an “issue-based” CMS, meaning that it divides article sets into issues, like a print magazine.

At any rate, I'm getting ahead of myself. What I was aiming to note in this entry was that I've really gotten my speed refined on posting. Posting a newsletter (30-40 articles) use to take me about three to four hours — that includes reading over things somewhat to make sure nothing gets lost in the translation from print to web, mailing out a teaser to “NewsAlert” subscribers, and updating The Navigator/Site of the Month link on FaithTree.com. The last few times I've posted the newsletter I've actually gotten that down to between an hour and a half to two hours. I'm pretty happy with that, although I've learned some places where SAFARI needs improvement.

This works out perfectly. As some Asisaid.com readers may recall, I started a project to create a new blogging software package in March. In actuality, the new software is version 2.0 of SAFARI, but with many improvements and ideas I've gotten since I released SAFARI IssueWorks 0.90 in 2001 (which differed little from the unreleased SAFARI 2000 that runs my church's newsletter and dated from… 2000).

My idea revolves around some simple concepts that I hope to reveal very soon. If all goes well, SAFARI ContentWorks, as I've nicknamed the new version, will provide some pretty neat stuff that will make posting my church's newsletter much easier and will also have some applications to blogging. Stay tuned.