Re: SUMMARY: Running X/Mosaic from behind a firewall
"Jason B. Bluming" <jbluming@yoyo.eit.com>
Message-id: <9309282030.AA26296@eit.COM>
To: Dave Crocker <dcrocker@mordor.stanford.edu>
Cc: Colin.Panisset@nms.otc.com.au (Colin Panisset), www-talk@nxoc01.cern.ch,
jbluming@yoyo.eit.com
Subject: Re: SUMMARY: Running X/Mosaic from behind a firewall
In-reply-to: Your message of "Tue, 28 Sep 1993 09:23:03 PDT."
<9309281623.AA18498@Mordor.Stanford.EDU>
Date: Tue, 28 Sep 1993 13:31:02 -0700
From: "Jason B. Bluming" <jbluming@yoyo.eit.com>
I've done some work with this idea already, though I used servicemail
services as intermediaries. Basically, when xmosaic would normally do
a GET, it instead sends an email message requesting that the servicemail
server retrieve the document. The server is also given a unique hash (MD5)
for the url being retrieved and sends the file to the local servicemail
process (on the xmosaic client machine) which stores the incoming data in
a spool directory under the hash name. Thus, repeated lookups (or multiple
client lookups) have access to already retrieved data. Using this scheme,
demos for at sites w/o stable net hookups could be done by pre-retrieving
those documents to be used in the demo.
This also brings about other issues, however. Since we have this ability,
and its associated overhead, should a pre-fetch facility also be developed?
If so how much should be prefetched (ie. how many or what type of child of
the current document are most likely to be needed or most time-consuming to
fetch?). What kind of "reaper" program should be used to keep the local
file spool within reason (LRU, LFU, hardest-to-load, etc...)?
=========================================================
Jason Bluming
Enterprise Integration Technology
jbluming@eit.com
(415) 617 - 8018 (office) | 459 Hamilton Avenue
617 - 8019 (fax) | Palo Alto, CA 94301
=========================================================
>dumb idea, but I'll offer it anyhow:
>
>There already is a mechanism for moving data across an arbitrary
>number or kind of firewalls.
>
>It's called email.
>
>Specify a Mime content type for web exchanges and ship things via
>email. This will, no doubt, create performance problems in some
>cases, but that can be attacked by making the firewall relays
>more efficient or handle some addresses differently, etc.
>
>The nature of firewalls is that they involve organizational policy,
>so that limiting the number of mechanisms operating on a firewall
>should help adoption.
>
>Dave
>
>P.S. There needs to be email-based Web access, anyhow, since many
>people don't have interactive access to the net, but DO have
>email access.
>
>d/