RE: Client side : an economic perspective was: Re:...

-----Reply from Andy Coniglio-----
1.	Clients do not have to implement every feature of the web.  They do not
have to be heavy.  I might add that pages should be designed with these
clients and their limitations in mind.

2.	Client side applications and scripts came about partly because servers
were getting bogged down with tasks that clients could perform.  The
Internet has a finite amount of computing power.  It also has a load that it
must carry.  It will run faster if the load is spread out.

3.	Not everyone has the security priveleges on a server needed to write
server-side applications.  In fact, much of the web developer population
can't or won't run a server due to inadequate connection or computing power.

4.	There are things that are not possible with server side scripts/apps.
Page formatting comes to mind.  Besides the dramatic increase in Internet
trafic, some things wouldn't be posseble.

5.	You mentioned "Client-side methods are difficult to standardize and
implement across platforms."  Any kind of server-side app would have to send
data back to the client to be displayed.  Any problems that are associated
with client side methods would also apply to this new Server->Client
protocol.  You may argue that it could be standardized.  Sure it could.  So
could JavaScript. (It has been; It's called ECMAScript.)  >Netscape and IE
don't use standardized DHTML.  That's because it is new and hasn't had time
to get a standard.

A possible solution to the problem of bogged down servers vs. heavy clients:
In a future generation of HTTP, there should be a header sent to the server
when a document is requested that specifies what scripts/apps the Client can
parse.  The server would run anything that the client can't handle.

The Conigs -- waconigl@mccallie.org

-----Original Message-----
First, the fact that it makes clients too "heavy", and with everything from
watches to TV sets becoming web-compatible these days, this introduces too
much extra overhead.
The client side should be kept as simple as possible. I think that HTTP-NG +
XML + CSS2 + DOM + ECMAScript is enough for any reasonable Web application.
Perhaps Java would make a nice addition to the above package, but there are
both licensing and implementation problems with Java. Perhaps if we get a
more "final" version of Java and we know that any future versions will be
backward-compatible, and a VM that's fast and open-source, we can talk...

The second problem is one that anyone who programs Java or JavaScript knows
already. Client-side methods are difficult to standardize and implement
across platforms. If the client side is kept simple, this will not be a
problem. The server-side can safely be kept proprietary. The number of
platforms that need to support server-side applications are very limited and
these can be developed safely.

The other problem is one that will become (I hope) apparent with HTTP-NG. If
we are going to have an object-oriented Web, we need to upgrade the server
side and slowly kill off the client side.

I think you are trying to approach the problem from the wrong angle. The
problem is *not* that servers often need to be as secure as clients, but
that the dominant format for the server-side right now is a file tree of
HTML documents. This is wrong. In order to provide proper implementations,
the information on the server side needs to be stored in a different format.
A sensible architecture for this is what is needed. CGI is not enough. It
usually uses languages like C or Perl that have much wider scope than web
publishing and hence create security risks for servers. Besides, CGI is just
a "patch" that sits on top of the familiar document-tree format. A
standardized, secure mechanism that stores and produces Web documents in a
different format would be more appropriate and solve the problems you
mention.

-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All I want is a little love and a lot of money. In that order.
------------------------- http://www.thor.cam.ac.uk/~sp249/ --

Received on Friday, 10 April 1998 14:18:13 UTC