Path: gmd.de!xlink.net!howland.reston.ans.net!usc!cs.utexas.edu!uunet!asirt8.aa.wpafb.af.mil!iris.mbvlab.wpafb.af.mil!blackbird.afit.af.mil!aedc-vax.af.mil!zone.aedc!c60201
Newsgroups: comp.infosystems.www
Subject: Re: cello
Message-ID: <1993Jul26.140840.485@aedc-vax.af.mil>
From: c60...@zone.aedc (Sean Fuller)
Date: 26 Jul 93 14:08:40 -0600
Reply-To: mcdon...@aedc-vax.af.mil
References: <i5FRsAtFBh108h@southport.on.ca> <CA6CFs.G78.1@cs.cmu.edu>  <CAJ1r2.JqE@cbnewsi.cb.att.com>
Distribution: world
Organization: Arnold AFB, Tn
Nntp-Posting-Host: zone.aedc
Lines: 46

In article <CAJ1r2....@cbnewsi.cb.att.com>, r...@hotsand.tbu.att.com (Rich Brandwein) writes:
|> 
|> In article <CA9F4F....@csc.ti.com>, peter...@osage.csc.ti.com (Bob Peterson) writes:
|> |> In article <will.742755010@ogre>, w...@ogre.cica.indiana.edu (Will Sadler) writes:
|> |> |> ...
|> |> |> 
|> |> |> If you do not have direct access to the Internet you will not be able
|> |> |> to use Cello.
|> |> 
|> |>   I hope this is incorrect.  We users sitting behind restrictive
|> |> firewalls can and do make use of tools such as Cello, Gopher, WWW, etc.,
|> |> to access servers running inside the company.  If Cello truly will not
|> |> run without direct access to the Internet, e.g., for critical files
|> |> fetched from some support site, then the tool is seriously broken.  I
|> |> suspect this is not the case.
|> |> 
|> 
|> Which brings me to one of my quibbles with Cello.
|> 
|> We sit behind a very restrictive firewall here and have been
|> "proxytizing" sources to mosaic, xgopher, etc. to get it to run
|> to the outside world as well as in (with lots of help, when 
|> asked, from the NCSA folks I might add).  The biggest problem
|> I have with Cello is that it's only distributed as an executable
|> which means we can't proxytize it.  For folks in our position, Mosaic
|> for windows is clearly the way to go - I assume you'll have access to the source
|> code.
|> 
|> By the way, anyone with experience/question on proxytizing let me
|> know.  We've proxytized Mosaic/emacs/xgopher/www/lynx/tkWWW, but there's
|> got to be a better way to build proxy code (for instance, we
|> need to sit down and go back into the code each time a new version
|> comes out).
|> 
I don't know what proxy software you are using, but if you are using
one of the later versions of socks it will be difficult to do what you
are asking.  I think the way to handle this is to write a program 
that automagically filters through the code and changes connects,
accepts, listens and such over to Rconnects, Rlistens, etc.  I am planning
on doing this for our proxy software, because I am now supporting
Xgopher, sgopher, ftp, Xmosaic, etc. and it is getting to be a pain
modifying the software.  Because it is such a simple an straight forward
conversion process for our proxy libs it will also allow us to easily
convert new software we get to work inside the firewall.  Our proxy
libs cannot be made available to the public, but if you have any questions
about how to write one I will gladly answer them.