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.

The reality is that the added note is the exception, not the rule.
Pages (and web apps) are written for the authors/clients browser.
Authors that write to spec seem to be in the minority - for the very
good reason that writing to spec means you wind up spending
non-trivial amounts of time working around bugs in the big two.

> 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.

ECMAScript seems to cover this quite nicely. So does Java, which I
personally would prefer to ECMAscript, as I trust it more, and it's
more generally usefull.

> 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.

Again, ECMAScript or Java should do this.

> 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.

And yet again. If you have examples of things that can't be done with
Java or ECMAscript, I'm sure there are many who would like to hear
about it.

> 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.

He listed ECMAScript as part of the technology that's "enough for any
reasonable Webl Application". 

Having an open, interoperable internet again would be a nice thing. I
don't see it happening anytime soon.

	<mike

> 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:43:24 UTC