Re: HTTP 1.1 As Universal Transport?

Rick Troth wrote:
>
>         We can probably all point to examples of other people
> and other products that have  "bitten off more than they can chew".
> Things that do one or two things really well,  and then grow into
> hydra headed monsters,  trying to be the be-all and end-all.
> Don't let this happen to HTTP.

Rick & co,
I don't want a hydra either but I have not yet found any alternative
to HTTP that today offers
  firewall support
  encryption
built-in in the WWW-client-products that have a 90% market share.

I think that the state of things for systems like Java requires
a quick fix (even a kludge).  This has already been done in
HTTP 1.0 by Netscape (keep-alive).  The semantics of the fix
should be _brutally simple_ while we are waiting for a distant
hopefully much better solution:

Something like
Server=>EVENT <eventnumber> <entity-body>
Client=>GOT_IT <eventnumber> <entity-body>
# These messages would be independent of the usual GET and POST stuff.
# There must first be a message from the client
  requesting a Connection=Events feature!
# No caching of any kind
# Naturally all messages and responses are still atomic.
If you need good reponse you may have to open two (or more)
  HTTP-connections.

As every client, server and proxy must anyway be rewritten to
support persistant connections (a bigger change than
my additions IMHO) I would go for a change now.
An internet without a firewall-supported, encrypted
asynchronous, persistant protocol is simply not very
fun!

But, really.  If you can get NG to run (in Netscape, Java, Proxies
and servers) within 12 months or so I will gladly take back every word.

Best Regards
Anders Rundgren

PS.  I will not bother you guys anymore unless you want it! DS

Received on Friday, 17 May 1996 02:54:18 UTC