Re: looking for: WWW based reservation system

dcmartin@library.ucsf.edu (David C. Martin)
X-Delivered: at request of secret on dxcern.cern.ch
Message-id: <199310071732.AA12533@library.ucsf.edu>
From: dcmartin@library.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu
Phone: 415/476-6111
Fax: 415/476-4653
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: sanders@bsdi.com, www-talk@nxoc01.cern.ch
In-reply-to: Your message of Thu, 07 Oct 1993 11:16:16 -0000
	<9310071016.AA04913@manuel.hpl.hp.com> 
Subject: Re: looking for: WWW based reservation system 
Date: Thu, 07 Oct 1993 10:28:40 PDT
Sender: dcmartin@library.ucsf.edu

Why not just use DTM?

dcm
--------
Dave_Raggett writes:

Proposal for a Notification Service mechanism
=============================================

Tony suggests using WWW for a reservation system, e.g. meetings and
room bookings etc.

I see potential for showing pictures of room name vs time of day
and using ISMAP to allow people to click on the room they wish to book.
The HTML+ forms mechanism will allow you to combine such images with other
fields thanks to a suggestion by Marc Andreessen for an image widget.

One issue is how to force regular update so that you see the effects of
other people making bookings without having to ask for a refresh.
A crude approach is to use the Expires: field in the HTTP response to
get the browser to regularly refresh the document. A better approach would
use a separate protocol for soliciting notifications of changes:

You would use WWW and HTTP in the normal way, but the HTTP response would
include info on a notification server, e.g. UDP host/port number.

The browser would pick up this info and send a datagram to the notification
server with the URL for the booking document. The server responds with
an acknowledgement including its time-out period.

The notification server then sends datagrams advising changes to all
its current clients for each such booking document whenever that document
changes. Using a datagram service is ok since packet loss isn't critical here.

For robustness, the notification server times-out each client after a suitable
interval, and browsers would be expected to periodically re-register.


How about it guys? Any volunteers to implement a portable notification server?

Dave Raggett