[7141] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: Web conferencing

daemon@ATHENA.MIT.EDU (Paul Burchard)
Mon Jan 9 22:32:21 1995

Date: Tue, 10 Jan 1995 04:27:22 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: burchard@horizon.math.utah.edu
From: Paul Burchard <burchard@horizon.math.utah.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>

Brian Behlendorf <brian@wired.com> writes:
> I've become increasingly convinced that conferencing
> could be more efficient using news://host/group rather
> than http://host/cgi-bin/whatever.  Comments?

The basic difference between those two approaches is where the  
"browsing smarts" reside -- client or server.  The path of your  
explorations suggests some of the pros and cons:

Pros for the server-side approach:  the browsing interface can be  
customized for the topic at hand and, more importantly, it can be  
instantly upgraded without all the distribution problems of ordinary  
software.   (Presumably these reasons attracted you to the server  
approach in the first place.)

Cons:  server-side smarts can be a heavy burden to both server and  
client.  The server must maintain "account" information for large  
numbers of users, even though the majority will make only brief use  
of the system.  And the user has the burden of trying to keep track  
of all the accounts on different servers.

In other words, both pure-client and pure-server approaches have  
serious disadvantages.  What is really needed is a client/server  
balance.

For example, if the amount of "user customization/preference" info is  
not overly large (up to a few 10K), server-side smarts can still be  
made efficient by relying on the client to store the user-specific  
info between sessions.  This can be done conveniently with current  
Web tools by providing users with a log-on page (laced with hidden  
form fields) that they can save on their own machines, and then  
resubmit to start a new session.  This allows the server to only  
maintain short-lived "session" state, rather than long-lived "user"  
state, and so is much more efficient.

Of course, more sophisticated client/server balancing is possible.

--------------------------------------------------------------------
Paul Burchard	<burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

home help back first fref pref prev next nref lref last post