As we saw in Part I, conferencing supports modes of collaboration that email handles poorly. But NNTP servers aren’t just bulletin boards that people can post messages to. They also provide discussion services that custom groupware applications can exploit in useful ways. In this chapter, we’ll see how you can use an NNTP server as a component that adds discussion features to two different kinds of groupware applications.
The first example connects an XML docbase—namely, the manuscript of this book—to a newsgroup. It enables a group of reviewers to comment on the chapters, subsections, and paragraphs in the book. We’ll use the NNTP API, along with the docbase’s web API, to implement this notion of a reviewable docbase. At the same time, we’ll learn how to write an application that uses an XML parser to read an XML repository, and transform it into deliverable web pages. The second example adds a discussion component to a helpdesk application. The primary data store will be an SQL database; it receives trouble reports by way of a web form. But that form’s handler also echoes the trouble reports into a newsgroup, so that users and IT staff can discuss them. Here we’ll also use the NNTP API to reorganize the newsgroup, moving trouble tickets and their associated discussion from an open to a closed status.
Both applications show that an NNTP discussion need not be an unstructured free-for-all. You can create a framework that ties discussion to the elements of a docbase or to rows in an SQL database. These uses of NNTP may surprise you. But they flow naturally from the Internet model of programmable macrocomponents.
The online bookstore Amazon.com enables readers to review books by posting comments to the web site. Of course, all books, including this one, undergo thorough review before they ever reach the reading public. Why not use Internet groupware to support that review process? Given tagged sources that comprise a book—or indeed any structured docbase—here’s a recipe for building a reviewable docbase with a discussion component.
Figure 9.1 shows part of a
newsgroup framework, based on a draft of this book and generated by a
Perl script we’ll analyze shortly. The
Subject: headers of the messages in the newsgroup
correspond to chapter and subsection titles extracted from the
docbase. The outline structure of the newsgroup also corresponds to
that of the book. Message bodies contain pointers—that is,
URLs—that lead to their respective docbase sections. This setup
alone can serve as a simple framework for a discussion tied to the
docbase. But it also sets the stage for a more sophisticated
application based on a specially instrumented version of the docbase.
As we’ll see, the script that processes the book’s XML repository into deliverable HTML pages also builds this newsgroup’s framework.
Figure 9.2 illustrates the fragment of the docbase that’s the destination of the Refer to docbase link in Figure 9.1. Note how each paragraph ends with a hyperlinked sequence number. These numbers are, in themselves, really useful. They enable reviewers to talk about “element 994” rather than “the fourth paragraph after the heading `web-client scripting’ in Chapter 8.” In an XML repository, every element’s end tag must be explicitly declared. That makes it easy for processing software to do something when it encounters an end tag—for example, to emit an element number.
It’s handy to be able to refer to numbered paragraphs. What’s most interesting, though, is the link wrapped around the numbers shown in Figure 9.2. Here’s an example of such a link :
/comment.pl?docbase=groupware.v3&chapnum=8&elt=994&id=925155710_156
&fragment=Chapter+8,+Section+Web-client+scripting,+Para+994,+What%27s+more,
+you+can+join+components+to+achieve+novelThe script invoked by this URL produces a form that quotes element 994 and solicits comments about it.
The comment.pl script mentioned in the previous URL does more of the same kinds of things we’ve seen already: it reads a form template, replaces markers in the template with corresponding CGI arguments, encodes those arguments in hidden variables for downstream use, and emits the modified template as the HTML form shown in Figure 9.3.
This form echoes the docbase element to which the comment will apply. The reviewer selects his or her name from a list, types a comment, and submits the form.
The handler for the comment form constructs an NNTP message that includes the chapter number, the NNTP message ID of the newsgroup message to which the comment should attach as a response, the reviewer’s name, the text being commented upon, and the comment itself. Figure 9.4 shows the state of the newsgroup after a comment has been posted.
A comment posted automatically from the form attaches neatly to its appropriate spot in the framework. Note, though, that users can also comment on a docbase section by replying directly to its corresponding placeholder message in the framework, without using the docbase’s comment form. That means they can violate the outline by posting new top-level messages or attaching responses to incorrect placeholders.
Should the outline be more tightly controlled? It could be. Chapter 13, shows how newsgroup authentication works. You could use these techniques to ensure that a newsgroup would accept postings only from a web-based agent and never from an interactive user. Should you? That depends. Document review typically involves small teams of collaborators. Often the best policy may be to provide a framework that organizes the discussion while still allowing communication to flow freely. I’d recommend trying that approach first. The point, after all, is to encourage discussion. You want people to be free to respond to one another’s comments.
Now that you’ve seen the application, let’s explore how it works. To do that, we need to follow two intertwined threads. In one, we’ll use an XML-parser-based script to read XML sources and write HTML pages. In the other, we’ll link those generated pages to a hybrid application that has a web frontend and an NNTP backend. We’ll tackle the XML part first.