Re: [MacPerl-WebCGI] query

[Bruce Van Allen <bva@cruzio.com>]

At 9:54 AM -0600 11/9/99, David Steffen wrote:
>This is in reply to the question posted by Jason Pidd:
>
>>I want a page to initially display a page with 2 frames , one frame
>>initially blank, the other containing approx 16 signs to an image...
>
>
>This is not so much a response to Jason's question as it is a 
>comment inspired by it.
>
>Jason's question, paraphrased by me:
>
>Multiple users are looking at the Web same page.  This page contains 
>two frames, one with thumbnails, one with an image.  When one user 
>selects a thumbnail, not only does that affect the image that user 
>sees in the other frame, but it also affects the appearance and 
>behavior of that thumbnail on the screens of all other users.
>
>If I understand correctly, this is double plus un trivial.  The 
>reason is that the transport protocol which underlies the Web, 
>httpd, uses transient connections.

[snip]

>http was never designed for interactive behavior.

Hmmm? I would say interactive via discete transactions.

>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.  The advantages of doing that rather
>than writing custom Java applets are:
>1) It promotes true laziness.  # <= obRelevance to (Mac)Perl
>2) It could be much more tightly integrated, so that the browser 
>could be instructed to load HTML via http via the other, 
>to-be-invented, persistant protocol.
>
>Comments?

Well, I too have bumped against the constraints of the http type of 
connection, and I agree with much of your thoughtful comment, but:

1. A server would be quickly swamped by multiple persistent 
connections of the protocol you suggest, unless that protocol really 
just fakes persistence by doing behind the scenes what http 
programmers do to maintain state, i.e., write to server files or pass 
cookies or hidden variables back to the user for the next round of 
interaction. Maybe Internet III will have the bandwidth for true 
persistent connections with the richness of http.

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.

3. The problem is what you correctly identified as Jason's thinko 
regarding web site viewing: "While one visitor to the site has access 
to an enlarged image..."  There is no "while" on the web, unless it 
is specifically programmed.

So the CGI could use a time stamp to mark images 'in use'.

4. But what's the point? :-) Jason, do you want the 'current' 
visitors to the site to know about each other? Is there some 
interaction among them that your site will promote? What is the time 
period of the 'current' moment? With no 'while', there's really no 
'simultaneous'. Two separate visitors 'viewing the same image at the 
same time' is a human narrative of what's happening, not at all an 
accurate picture from the perspective of machines and electrons.

If visitor A clicks a link to view an image, and then viewer B on 
another browser clicks a link to view the same image  1 millisecond 
later, the server would do its job no differently than if B clicked 5 
hours later, or two months. And the response experienced by the users 
would be no different.

Incidentally, (David knows this), congested web sites slow down 
because the server must handle responses to many requests in a short 
time period, _not_ because certain files are 'in use' (even most 
database accesses are very brief; yes it's important to lock files, 
but that's for data integrity not access speed). So if Jason's goal 
is speed, this isn't the way. A script that would select an 'unused' 
image would not be doing the server any speed favors by preventing 
'simultaneous' image file accesses -- in fact, CGI scripts inherently 
take more server cycles than web page hits.

Oops, getting too verbose here.

Jason:

To go the Perl route (highly recommended in this neighborhood...):

1. learn about CGI.pm -- it's probably part of the Perl installation 
on the server where your site is. It can handle the CGI transaction 
without much pain.

2. learn about reading and writing files.

3. learn about how to parse a line from a file.

possible file format:

time_stamp|file_ref
3024987827|big_cat.jpg
3024987875|red_fox.gif
.
.
.

If this is all beyond your experience, then you either have a 
learning curve ahead with [Mac]Perl, or you'll need to describe your 
project more specifically and ask very targeted questions to get help.

Good luck!

1;

- Bruce

_Bruce_Van_Allen___bva@cruzio.com__831_429_1688_V_
_PO_Box_839__Santa_Cruz_CA__95061__831_426_2474_W_

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