This is an outline of a computer-based communications facility that I'm calling ``Eubie'' because it sounds like UW BB and in honor of a notable American musician. The outline doesn't cover everything, but at least introduces a lot of the issues.
This project covers a lot of ground in when seen in terms of overlap with other services, but on its own terms it should present a consistent model, insofar as possible within the limitations of the interfaces involved. At the service implementation level, a reasonably small amount of software should support the whole thing, and support the introduction new types of data and interfaces without obsoleting existing parts of the facility.
The arrival of the World Wide Web is great news for this project, because it gives all the desktop platforms powerful, flexible information access with a common network protocol. It's a head-scratcher in some ways because some aspects of a conferencing system aren't well supported.
One major challenge is unsolicited events. The ordinary mechanics of browser-server interaction rely on the browser to initiate any request for new information - naturally, since browsing means to take something in at your convenience. The model implies that the data is more or less static.
In a conferencing communications facility, users will naturally want to be kept abreast of developments as the happen - the arrival of a new message, other people signing on and off, etc. A static model is adequate for some degree of message exchange, but poses severe limits on interaction.
Server push is a potential way to implement dynamic updates. It's definitely not a standard feature of Web clients and servers - it's supposed to work in Netscape, which has a bad reputation for hacks and kludges like this, but their description of the mechanism makes it sound like something that could potentially be supported in other browsers. Our server on weber doesn't seem to handle this feature correctly either, but we don't have to use that server.
In general, we're implementing something on the fringes of what's possible with today's Web software. Preferences are, first, features commonly supported today; second, features envisioned in proposed or accepted standards; third, features available in source-available software; and last, features available in commercial, licensed software.
The Library catalogue folks in our midst are interested in the integration of Web browsers with information retrieval facilities (Willow) that can't be translated to hypertext. That may have some liabilities, but it could turn out to be an interesting alternative model.
There is some existing Kerberos support for Web clients. One approach encrypts Kerberos 4 keys in the HTTP stream; another (commercial software from EINet) opens a separate Kerberos protocol stream. I don't know which tack it takes, but there's supposed to be an NCSA httpd and browser that authenticates with Kerberos 5 beta 5, and that's where we'd start.
Authenticated Web access, with a large cross-campus user data base, is likely to be valuable outside the scope of this project.
I'm using this term to suggest an increase in the accessibility between people on campus, using computers. With all the use our computers get in this capacity, I think they present a very opaque, awkward medium for it. Some of the improvements will come in our design of the message protocols and interfaces, but there are also some services that don't involve messages.
I don't think there's any need for unsolicited messages, but some kind of ``R. Johnson is calling'' phone ring should be at least optional. This is basically related to ``there are new messages in ...'', and probably should be handled the same.
Users will also need some persistent state for their own purposes (and ours), like what they've read, what they own or have shared responsibilities for, and various preferences and memberships.
Threading would be worth looking at - internal threading based on where what you follow up, and/or maybe some algorithmic approach. The latter shows up in a Web conference I looked at, where it seemed to be prone to error.
HTML in messages. Where I've seen this done, there's no extra layer of quoting or whatever - any valid HTML text in the message is hyper, which sometimes makes for bogus links. I think that's OK.
One of the most valuable contributions this project could make would be a medium for computer-based communication that incorporates some of the good things about in-person oral communication. People have a lot of communications skills, though they may not be very consciously aware of them, and if a computer medium could make use of those skills it might make communication much more productive. For example, we have various audible and visible flags we use when preparing to say something, and (in the best case) others will recognize this and possibly prepare to defer their own comments. That's a blind spot with computer media, and I'd like to look at it.
In general, the priority here is to emphasize and facilitate civil discourse. Part of that may mean allowing users to take some responsibility for their own conference - at least the nominal ``owner'', but perhaps there would even be ways for users to work together to discourage disruptive behavior.
Someone in Communications or wherever might be interested in a thesis or something relating to this project.
The big question seems to be how to squeeze the most Web compatibility out of the design, and that's going to take more research in fringe Web technology.
A distributed implementation is undoubtedly called for, for scaling reasons. That means not only the ability to install and access services on various different hosts, it means designing the protocols so that a service connection can be routed according to various useful criteria. (For a bad example, consider the limitations of things like telnet in a clustered environment - while it might be interesting to route telnet connections to a particular cluster member depending on where the user's home directory is mounted, the telnet protocol simply can't accommodate that.)
The data service that handles a particular topic might be implemented as a single process that arbitrates access to the data, deletes and adds messages etc., plus processes to handle incoming connections in various protocols (e.g., IMAP, NNTP). This allows synchronous updates to the data without the always problematic filesystem locking, and makes room for some protocol-based abstraction of the data. Initially a lot of the data may be Berkeley folders, or for a fairly transient topic (i.e., highly interactive chatting) could be held in memory.
Protocols directly supported by the data service should include IMAP, NNTP, SMTP, maybe HTTP, maybe old bb clients, maybe Zephyr. plus others as required for implementation. SMTP support should extend to receipt of incoming messages (initially via sendmail and filter), and mailing of received messages (via listproc - i.e., Eubie will not be a mail repeater, but may forward messages to listproc for that purpose).
The site service that handles user accounting, preferences and state information should also be a distributed design, including politically - we should be prepared to handle all of this, but if another department or whatever wants to maintain their own site, that should present no problem.
This system should attempt to decentralize administrative tasks just as it distributes support across hosts. The principal accounting data will probably reside in our central Kerberos realm, but other realms may be involved. Support for particular data services or site services may be assumed by other departments or institutions without any special blessing from the ACC.
Ideally there would be little or no administrative overhead, but in practical reality there probably will be a fair amount, because we will not want to open the system wide up for everyone to use any amount of resources. I think we'll want to place limits on the number of conferences that may be created, and on the amount of message data, and so forth. Probably we'll charge people for some of this stuff (like message data) through existing disk quota procedures. I think messages should be charged to the people who post them, but we'll have to look at the overhead in that.
The potential decentralization of this system is an issue to consider here. It's probably in the University's interest to have the bulk of general purpose stuff handled on our site, but if we want to actually control that we should decide that now and design the system so that other departments can provide services only with our approval, and not for example dorm room Linux PCs.
There may also be some kind of group concept, relating to access privileges, that will require administration. I think that's only going to be a productive approach if group membership is made the responsibility of the group user-owner.
I have something called Zephyr, an MIT Athena project. It's running on melville at the moment. Zephyr is a message sending/broadcasting system built around Kerberos authentication. It looks like something we could actually use internally - kind of like an X version of the UNIX write command. At worst, it represents the work of people who've been running an authenticated message facility for years and have thought about the issues.