Re: [MacPerl-WebCGI] query

[David Steffen <steffen@biomedcomp.com>]

In reply to my statement:

>>However, there is nothing that would forbid adding the ability of 
>>Web browsers
>>(which are already more than just http clients and HTML renderers) 
>>to communicate via a different protocol.

Bruce Van Allen said:

>1. A server would be quickly swamped by multiple persistent connections

Potentially, without a doubt.  Persistent connections on slashdot 
would be a nightmare :-)  However, telnet does work because typically 
it services many fewer clients than does a typical web server.  I had 
guessed that Jason was setting up a system to service a limited 
number of clients, something I do frequently.  In that case, the cost 
of persistent connections can be tolerated.

>2. What the original poster (Jason) wants wouldn't be that complex - 
>just a little data file listing his images, and a CGI script called 
>by the thumbnail image links that would mark images in the data file 
>'in use' or not while it grabs and returns a reference to an image.

I think your answer is much more helpful than mine because it made a 
more reasonable assumption.  I had assumed that Jason wanted the 
thumbnails to update in real time, so that if Jason has been staring 
at his web page for the last hour, and I all of a sudden select a 
thumbnail, the web page on his browser updates immediately, without 
him doing anything.  That requires a persistent connection.  You 
suggested that Jason's page only change when he did something.  Thus, 
he might select an apparently available thumbnail only to be told 
that it is now unavailable.  That, as you pointed out, is easy.

The reason I made my assumption is that there have been times when I 
have really needed persistent connections and would love to have a 
browser with a persistent connection protocol integrated into it such 
that the persistent connection could drive updates of the HTML 
information.  Java:
1) is too much work to be justified in many applications,
2) doesn't integrate well with any HTML on the same page,
3) isn't MacPerl and doesn't belong here :-).

Granted, such a browser would make much heaver demands on a server, but:
a) most websites wouldn't offer a persistent server,
b) the ones that did presumably would service fewer clients and in 
many cases probably would only be available to a limited set of users.

Unfortunately, there may not be enough demand for such a browser to 
drive its development :-(

So what does this have to do with MacPerl?  Well, er, if you 
implemented the Java solution, it could contact a server on a Mac 
written in MacPerl <-) (is that a sheepish grin?  It's supposed to 
be.)

-David-
 
David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com

==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org