10-12-00 Preface: This article was written in June. I’ve changed a few things around with the comments system I developed for my Blogger-powered weblog Web Queeries, but I’m still very much in support of my initial idea: static comment pages for Blogger blogs would be more efficient than dynamically-generated comment pages.

• Introduction
• Examples of Comment Systems
• Static vs. Dynamic Documents
• Proposed Tags
• Technical Implementation
• Conclusion

Introduction.

Members of the group Blogger-powered weblog I edit, Web Queeries, wanted to be able to post comments on posts, so I created a PHP/MySQL work-around comment mechanism. While trying to create a comment system, I brainstormed several ideas about how I would like to see Blogger implemement a native-comments system.

This document is intended to be an open letter to Blogger, suggesting a method to implement a native-comments system. At the end of this document is a forum for readers to add their own suggestions and feedback about this document.

Examples of Comment Systems

Currently, some bloggers have implemented proprietary comment systems. Several use traditional bulletin boards. Blogs like Eleven Seconds have signed up with bulletin board services. Blogs like Prolific have set up server-side bulletin board CGI scripts.

One of the difficulties with using a traditional bulletin board system for blog comments is coordinating threads on the bulletin board with specific posts in the blog. Also, it can be difficult to display under each post in the blog how many associated comments have already been posted.

Other non-Blogger weblogs, like Metafilter or MetaJohn (or hit-or-miss.org) have integreted comment systems. Under each post is a comments link showing the number of comments already posted. Clicking on the link usually takes you to the permanent location for the individual post, which includes the comments that have already been posted. These comments systems are implemented using a SQL database and a scripting language.

Static vs. Dynamic Documents.

One of the most attractive features (imho) of Blogger is that it creates static pages for the user. Users who either do not have the knowledge to write blog scripts or do not have the access to run scripts on their server can, with Blogger, change the template for their blog and add, edit, and remove posts all with the touch of a button. Blogger does all the work, but it creates static documents so the content of blog doesn’t have to be generated dynamically by Blogger each time someone wants to view the blog.

Following the Blogger model, it would seem obvious that an efficient way to implement a Blogger comment system would be to continue creating static documents.

As discussed above, blog comments can either be displayed in a separate bulletin board or attached to specific posts. I tend to favor the latter. Like on Metafilter, Blogger posts can be seen in a permanent location. But unlike Metafilter, they are part of a scrolling archive for the week or a day.

My suggestion would be that Blogger create a system to display comments statically by inserting them after the posts they’re associated with in the archive file (not the current file). Everytime a comment is submitted, Blogger would FTP over the new files containing that comment.

2000.06.23 Update: Pete wondered it’s really efficient to continue to FTP a new static comment page after each update. Suppose you have 5 or 10 people submit a comment a day, resulting in 5 or 10 additional FTP transfers beyond your own posts to your blog a day. But suppose you have 50 to 100 people read those comments a day. Using a dynamic comment system, the Blogger server would have to dynamically generate those comments for viewing 50 to 100 times a day. Thus, I still consider the static method to be more efficient.

The comment system I created for Web Queeries mimics the format I’d like to see a native-Blogger comment system work.

Proposed Tags.

Use of the comment system would, of course, be entirely optional – just like the use of many blogger tags and features are optional.

Here are the new Blogger Comment Tags I would propose:

• <$BlogItemNumberOfComments$> – the number of comments associated with a post.
• <$BlogCommentBody$> – The text of a comment.
• <$BlogCommentAuthor$> – The author of a comment.
• <$BlogCommentAuthorEmail$> – The email address of the author of a comment.
• <$BlogCommentAuthorURL$> – The homepage URL of the author of a comment
• <$BlogCommentDateTime$> – The Date and/or Time of a comment.
• <$BlogCommentNumber$> – The unique ID number of the comment. Formated as “c#” to distinguish it from post IDs.
• <$BlogCommentLink$> – The url for the form to add new comments to this blogger post.

There would also be the <BlogComment> </BlogComment> to mark the beginning and end of the comments section. Within these tags, the <BlogCommentHeader> </BlogCommentHeader> and <BlogCommentFooter> </BlogCommentFooter> could mark the beginning and end of the comments section.

Here’s an example of a Blogger Template using Blogger Comment Tags.

<Blogger> <BlogDateHeader><h3><$BlogDateHeaderDate$></h3></BlogDateHeader> <a name=”<$BlogItemNumber$>”></a> <blockquote> <$BlogItemBody$><br> <smaller> Posted by <a href=”<$BlogItemAuthorURL$>”><$BlogItemAuthor$></a> | <$BlogItemDateTime$> | <a href=”<$BlogItemArchiveFileName$>#<$BlogItemNumber$>”>Link this post</a> | <a href=”<$BlogItemArchiveFileName$>#<$BlogItemNumber$>”>Discuss</a> (<$BlogItemNumberOfComments$>). </smaller> <BlogComment> <blockquote> <BlogCommentHeader><p><b>Comments:</b></p></BlogCommentHeader> <p><$BlogCommentBody$><br> <smaller>Posted by <a href=”<$BlogCommentAuthorURL$>”><$BlogCommentAuthor$></a> | <$BlogCommentDateTime$> | <a href=”<$BlogCommentNumber$>”>Link this comment</a>. </smaller></p> <BlogCommentFooter><p><a href=”<$BlogCommentLink$>”>Add your comment</a>.</p></BlogCommentFooter> </blockquote> </BlogComment> </blockquote> </Blogger>

This would produce the following kind of output:

 ->

Through the creative use of table nesting and color, the comments section under each post in the archive files could be made less obstrusive.

Technical Implementation.

A SQL table would be created to hold the comments for each blog (just like there’s a table the posts of each blog). The primary key would be the Comment ID. The table would also have columns for the ID of the post the comment is associated with, the time/date of the comment, the name of the commentor, their email and/or url, and the text of the comment.

Many feedback services require that a commentor be registered with their service to be able to post a comment. Blogger could either use that method (meaning instead of storing a name, email, and URL, the comment table would just store the user ID), or just allow anyone to post a comment (allowing for anonymous comments).

2000.06.21 Update: Several readers have pointed out to me that Blogger is an extension of the Pyra application, which requires users to be logged in with a username and password. It is my impression that the Pyra application kind of works more like a traditional bulletin board system than like a comment system (which is what I’m proposing). Thus, I still think that it makes sense (following the Blogger model) to propose that a Blogger native-comment system create static documents (like it does for Blogger posts). Creating a user id for each random person who wanted to write a comment in someone’s blog would seem to me to require too much overhead from Blogger. Thus, I’d like to see anyone to be able to post a comment (anonymously or maybe with their Blogger ID if they have one).

Because static documents are being created, Blogger should filter all comments for Javascript, SSI, PHP, ASP, etc scripts that might be run when a user viewed the page containing the comment.

Every time a comment is posted, Blogger would generate a new copy of the blogger.html file (or whatever the user renamed it to) updating the output of the <$BlogItemNumberOfComments$> tag. Then, it would generate a new copy of the archive file containing that post, inserting the comment.

To post a new comment, a reader would follow the link provided by <$BlogCommentLink$>. This URL would contain a query string specifying the ID of the blog and the ID of the post the reader wanted to comment on. The comment form would be run off the Blogger server, like the forms for editing individual blogs.

Additionally, Blogger should allow the administrator/owner of the blog to edit and remove comments (i.e. to be able to delete abusive comments or spamming). The link for editing/removing those comments could be displayed after the posts in the current posts editing window.

 ->

Conclusion.

The main stumbling block to the above proposal is, of course, are whatever plans Blogger might have already have in mind for creating a native-feedback/comment system. I hope, however, that the folks at Blogger will consider my basic ideas about
static vs. dynamic comment systems. I do continue to feel that the best feature of Blogger is that it creates static documents that do not rely upon Blogger’s server to be viewed. I truly believe that a similar comment system would be in Blogger’s best interests.

The contents of the above document were written by Matthew Kingston on June 20, 2000 (except where noted). Matthew hopes that Blogger will feel free to use any ideas contained within this document towards the purpose of creating a native comment system. Matthew does not expect any compensation or credit for sharing these ideas (though a Blogger t-shirt would be cool).