Re: multithreaded libwww

wei@xcf.Berkeley.EDU (Pei Y. Wei)

Mail folder: WWW Talk Apr 94-present
Next message: pel@syl.nj.nec.com: "Re: multithreaded libwww "
Previous message: Paul Leclerc: "Re: commercal web browsers "
Maybe in reply to: Garrett Arch Blythe: "Re: multithreaded libwww"
Reply: Tim Berners-Lee: "Re: multithreaded libwww"

Errors-To: listmaster@www0.cern.ch
Date: Fri, 13 May 1994 06:21:42 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405130419.AA15481@xcf.Berkeley.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: wei@xcf.Berkeley.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: wei@xcf.Berkeley.EDU (Pei Y. Wei)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: multithreaded libwww
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Garrett Arch Blythe <doslynx@falcon.cc.ukans.edu>:
>         By multi-threaded, I take it you mean having multiple documents
> you can pull up and take them in the direction that you want independent
> of the other loaded documents.

Specifically, I'm looking forward to the WWW library being able to handle
multiple independent time/cpu-sliced HTTP operations. This way, a browser
doesn't have to halt all user interactions (save the HTTP interupt) until
after all HTTP operation is completed or interrupted. 

With threading, for example, you would be able to read/scroll/following-links
in a page-screen, while another screen is busy doing HTTP "in the background".

Also, with multi-threaded HTTP, the <INCLUDE REFRESH=...> idea would be
more practical. Although I've implemented that dynamic feature in ViolaWWW,
at this point it's not terribly practical if the refresh rate is short,
because the UI will stop while the refresh is happening.

-Pei