Presented at: TERENA-NORDUnet Networking Conference 1999 Full name of authors: Jacob Palme, professor Organizational affiliation: Stockholm University and KTH Address: Skeppargatan 73, SE-11530 Stockholm, Sweden Phone: +46-8-664 77 48 E-mail: jpalme@dsv.su.se URL in HTML format: http://cmc.dsv.su.se/talkback/talking-back.html URL in PDF format: http://cmc.dsv.su.se/talkback/talking-back.pdf
Abstract: While e-mail and netnews support interaction between users, typical WWW communication is uni-directional -- from the web page creator to the reader, but with no facility for talkback from the reader to the creator or between readers. This paper discusses how talkback can be added to the WWW and presents how this is implemented in the KOM 2000 system.
Status of development.
Interactivity
Two or more people can exchange information in both directions. Note that this is people-to-people interaction, not human-computer-interaction.
Talkback
Web page readers can reply to web pages, and discuss the web pages with other readers of the same web page. Note: The word "annotation" is often used for what in this paper is named "talkback".
The three largest applications on the Internet are:
The main difference between WWW on one side, and e-mail/netnews, on the other hand, is that WWW is mainly used for unidirectional publication of information, while e-mail and netnews are mainly used for interactions between users. E-mail and netnews has the following two primary functions which are not generally available on the WWW:
Reply
Send a message which comments on a previous message, written by someone else, often to all recipients of the previous message.
Submit
Many people can submit to the same group of recipients (mailing lists, newsgroups).
There have been many attempts at providing talkback in the WWW. Here are some methods:
Since the HTTP/HTML protocols, combined with forms, can be used as a fairly general-purpose application interface, they can of course also be used to provide interface to applications which provide interactivity between people. Examples of this is forums (web-based, non-same-time conferencing systems), chat (same-time text interaction), web-based e-mail, like for example Hotmail and MUD (multi-user adventure games).
The talkback facility in these systems is limited to users of these special services. Usually, talkback is only possible between those users who connect to one single server. Talkback is thus not very well integrated in the normal WWW structure of a vast distributed data base of documents with hyperlinks not only within servers, but also between servers.
A few experiments have been made in providing talkback directly in web pages. The most common method is to append, at the end of an ordinary web page, a talkback button, and lists or links to responses. A reader of such web pages can thus send in their responses, and have these responses added to the web page. Example:
For the following reasons, I think that the moon is made of green cheese ... ...
Your name:
Another variant only puts a single button at the bottom of a web page, which links to a place where this web page is discussed. This variant does not intrude on the primary contents of the web page as much as where the discussion is put inside the web page itself.
Talkback facilities can be provided through two different methods:
As is shown by the table above, there are serious problems with both methods. An ideal talkback facility should combine the following services:
Web page owners can insert talkback into their pages, this talkback is then available to everyone who reads this web page. This is similar to what is named Local talkback service in the table above.
Users interested in talkback can subscribe to a talkback service, and they will then be able to enter forums on any web page. This is similar to what is named Universal talkback services in the table above. But the talk back servers are interconnected, so that all readers of each web page share one single forum area for that web page.
These two services are combined, so that the forum area provided with a Local talkback service is the same as that provided by the Universal talkback services.
Sometimes, it might be suitable to have a joint forum area for a set of related web pages, instead of a separate forum area for each page.
Sometimes, an organization might want to have a Universal talkback service, but only available for members or employees of this organization.
A universal service is not easy to implement. Since a fundamental principle of the Internet is that nothing should rely on one single universal server, a distributed, standardized protocol is needed. This protocol should provide the following services:
Access for local talkback services, so that a web page owner can add talkback to his/her web pages.
Global access which can locate the talkback areas for one particular web page (or a set of related web pages). This requires some kind of directory data base, which given a web page URI, can locate the talkback area for that particular page.
The talkback areas might be stored in conjunction with the web page(s) they are connected with. But it is natural, in the WWW, to have the talkback areas distributed, so that every author of a talkback message can provide his talkback message as a web page on a local web server. A central area for each web page might then only store links to all talkback for this particular page. It might also store cached copies of the talkback pages.
In an earlier research project, Web4Groups, we implemented a simple service of this kind, but this system was experimental and never achieved production quality.
We are working on a new implementation in the KOM 2000 system. KOM 2000 is a distributed service of interconnected KOM 2000-servers. Each KOM 2000 server stores the items submitted by its local users. Each server can also hold multiple forums, both those connected to ordinary web pages and those not connected to a particular web page. The forums can be of different kinds, such as open to everyone, closed for members only, open to members of another group; moderated or allowing every member to write in the area. A beta version of KOM 2000 is already available on the web.
Items in the data base are of primarily three kinds:
Users.
Documents (pages, messages).
Forums (discussion areas).
Each item (user, document, forum) has
A URL associated with a file, just as for ordinary web pages. This is, like all URLs, a globally unique identification of this item.
A title, which is a user-friendly name, not limited by the limitations of the URL syntax. This name is not guaranteed to be globally unique.
With each user is associated a private area, an inbox and an outbox, and lists of forums to which this user is associated as member or as organizer.
With each forum is associated
a list of contributions in HTML format.
a list of members. Different members can have different roles, such as ordinary member and organizer of this forum.
a list of subactivities.
Example of data base structure within one server:
The data base is distributed: Users submit their contributions to their localKOM 2000 server, but forums can be available to users at multiple servers. Each forum is located in one server. Every user has a home server, and accesses all information through his/her home server. This means that the actual URL seen by the user when accessing an object at the server cmc.dsv.su.se from a user at the home server foo.bar.net can be http://foo.bar.net/cmc.dsv.su.se/flowers/tropical/1, where http://foo.bar.net/ is the home server of this user, and cmc.dsv.su.se/flowers/tropical/1 is the identification of the object. The local server of this user will retrieve the object from its home server.
This, unfortunately, means that the URL to access the same forum differs for different members. However, IETF has standardized a facility called Uniform Resourch Names (URN). When web browser support URNs, look up of a web page is a two step process. First the URN is used in a URN server. This server will return a URL, where the actual document is placed. The intention with this service is that the URN need not change when a document is moved, and that the URN server can provide links to the nearest copy for each user, for documents which are mirrored on different sites. But URNs can probably be used to overcome the problem above. The URN server can be designed to give each user access to an object through his preferred groupware, which is exactly what we need. Another possible solution might be a plug-in to web browsers.
To reduce access times, a copy of every object is stored at every server, where there is a recipient to this object. These copies can be removed to save space. If a user needs a document which has been removed, it can be fetched from the master server for this document. One can compare with Usenet News, which also copies articles to all servers. But our design has two advantages, compared to Usenet News:
Copies are not sent to servers where there is no reader of them. Replication is set up automatically when a reader starts subscribing to a forum. Usenet News cannot do this, because it has no list of the subscribers of the newsgroups.
If an object has been purged to save space, it can be fetched from a master server. In Usenet News, there is no automatic way of getting a copy of a purged article.
A master copy is stored at the server of the creator of the object, a shadow copy at the server of the forum and the server of every member of the forum. Thus, for example, an object may have three locations:
The protocol between groupware servers contains operations like:
The protocol uses the ticket method for access control. This means that anyone who has a certain access right is given a ticket, which is a randomly generated key. For example, members of a forum have the ticket for that forum, and when they retrieve a list of the contributions to the forum, they get the tickets for each contribution, which they then can use to download the contribution.
The advantage with this method is that no central certificate server is needed. And setting up certificate servers has been a major stumbling block in getting security systems working. We may however add use of encryption methods for authentication, signatures and seals to increase the security.
When this is written, we have not yet developed the directory system. We have agreed with a major search engine provider, that they will set up the directory. They will set up a directory, which given a web page, can find a discussion forum for that web page. The directory will not be limited to KOM 2000, it will be able to store discussions using other groupwares than KOM 2000 too.
There will be a protocol for the groupware servers to communicate with the directory system. Main operations in this protocol will be:
The format for these operations will be the same format which is used when a user fills in and submits a form on a web page. This means that also other groupware servers than KOM 2000 can report forums. Their owners can do this manually, by filling in a form on a web page, even if they have not implemented the protocol in their software.
The directory should of course also be distributed, based on an existing directory structure like LDAP or DNS, but our first implementation will employ a centralised directory only.
Woolley, David R., 1995, 1998: