Possibly, but I would have to disagree to a point. I have friends and
family that work for Intel, Microsfot, IBM, Cisco, HP, and Fujitsu. And
even though a lot of originizations have a standard proxy that handles
HTTP, FTP, GOPHER, there are many that do not.

Three friends I have at Intel all have different proxies for FTP and
HTTP and NNTP. The friend that works at IBM has a separate FTP proxy
from his HTTP proxy. I thought that most orginizations had standard
proxy as described, but as I inquired amongst the tech people I know, I
found out that a much larger percentage of the tech and especially
the R&D world do not. Many sites separate out HTTP traffic from FTP
traffic. Many don't. It depends on the bandwidth and policies of the
orginization. Not to mention resources (money).  Perhaps it would be
nice to change the installation prompting. Edit rebol.r in REBOL_HOME
and add the questions you want and and have it set the protocols as
such.

You also have to look at 90% of the Internet Users ( Joe Surfer at
home ). The way it is setup with a default for all, suffices just fine
through an ISP. Probably 90% of all apps will be used under one of two
scenarios; Joe Surfer at home or Joe Worker behind a firewall. For Joe
Worker, behind a firewall, 90% of any Apps they would run, I would hope
would be within the firewall and not outside of it. For the other 10%,
well I guess that's what tech people are for, to help set things up
properly. I think that overall it is setup correctly. If it suffices for
90% of all potential users and the other 10% need protocol refinements,
then the global system default should be where it is at. My only fault
with this would be that the set-user function out of rebol.r should
possibly prompt for the individual protocols after prompting and setting
the system/schemes/default/proxy. set-user should ask 'Use defualt proxy
for protocol 'XXXX' (Y/n/disable)? If you answer yes then it should
similarly ask for all fields of the protocol 'host' 'port-id' 'user'
'pass' 'type' 'bypass' . Your average user though will not have any idea
on how to set these up or what they even mean. The 'View' installation
is probalby what will eventually be the interface for most apps and I
would suppose that looking at the recent Beta [Prefs] button, that you
could write your app to display any and all system settings in a type of
control panel and just use radio buttons to enable/disable, use
default/custom proxy settings on individual protocols and have text
fields displayed for the settings.

The rest of the areas where you may need proxy settings for apps is on
servers themselves ( http w/ rebol cgi ) ( rebol servers ) and if you
don't know how to setup proxy access from the server through the
firewall securely after reading the network documentation (which is
really straight forward), then you need to show the network
documentation to your own LAN/WAN tech people so that they can help you
out.



----- Original Message -----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 31, 2000 1:24 PM
Subject: [REBOL] [ALLY] Email and Proxies Re:(4)


Thank you Stephen for putting it so well.
If a proxy is specified in 'set-net', Rebol
should only 'turn it on' for HTTP, FTP, and
Gopher. All other services should remain false.
This scenario would cover 90+ percent of
proxy users. It would also make distribution of
Rebol apps easier as less customization would be
required by the end user.

Greg Piney
S&P Web Engineering
[EMAIL PROTECTED] on 08/31/2000 02:50:16 PM
Please respond to [EMAIL PROTECTED]



To:  [EMAIL PROTECTED]
cc:  (bcc: Greg Piney/McGraw-Hill/US)

Subject:  [REBOL] [ALLY] Email and Proxies Re:(3)




Most of us are aware of the work around for this behaviour but I believe
what Greg was actually suggesting is that it would be more useful for
REBOL to set up it's proxy configuration more correctly for the selected
proxy type. That is go ahead and load the defaults perhaps for cern or
socks, but insert false value assignment statements in the user.r for
schemes that are not typically handled by that proxy type. Most notably,
SMTP for example wouldn't be handled by cern or generic proxies.

I have to sympathize in this regard as I use the generic proxy type and
I
either have to configure REBOL when prompted for no proxy then add the
assignments for the one scheme (HTTP) that requires the proxy or
configure
the proxy settings then go back and add false assignments for all the
other schemes that can't use that proxy.


Later,

Stephen

On Thu, 31 Aug 2000 [EMAIL PROTECTED] wrote:

> Rebol does do all that you expound on. Check out
http://www.rebol.com/docs/network.html
>
> Every protocol can have its own, proxy :: port :: type :: userid::
password ::
bypass rules.
>
> It appears that you are just setting your system/schemes/default/proxy
settings and not
> defining any of the individual protocols - system/schemes/smtp/proxy,
etc. In
the absence of
> defining any individual protocol settings, rebol then uses the default
settings. In addition, if
> you want to entirely disable proxy settings for a particular scheme,
you can
set the proxy settings
> to false.
>   ----- Original Message -----
>   From: [EMAIL PROTECTED]
>   To: [EMAIL PROTECTED]
>   Sent: Thursday, August 31, 2000 10:14 AM
>   Subject: [REBOL] [ALLY] Email and Proxies Re:
>
>
>   Wrong answer.
>   My SMTP server is 'local' on the WAN. It appears
>   that all IP traffic gets routed to the proxy
>   if you define it in set-net. Our cern proxy is a
>   proxy, not a firewall. We use a 'pac' file for
>   routing. This 'pac' file is usually loaded into
>   the Browser as part of auto configuration. The
>   browser can then determine which addresses are
>   'direct' (no proxy - on the WAN). All other addresses are
>   sent to the proxy. This is a pretty standard
>   setup for a large corporation.
>   The real answer here is that Rebol should not
>   proxy a service unless proxy is defined for that
>   service. Especially those a 'cern' proxy doesn't
>   handle. By default, only HTTP, FTP, and gopher
>   should be sent to a proxy. All other services should
>   be sent direct unless a SOCKS proxy is defined for
>   that service.
>
>   Greg Piney
>   S&P Web Engineering
>
>   Terrence Brannon <[EMAIL PROTECTED]> on 08/31/2000 10:45:04
AM
>
>
>
>   To:  Greg Piney/McGraw-Hill/US@MCGRAW-HILL
>   cc:  [EMAIL PROTECTED]
>
>   Subject:  RE: [REBOL] [ALLY] Email and Proxies
>
>
>
>
>   [EMAIL PROTECTED] sent a msg to the REBOL list about 2-3 days ago
stating
that
>   you cannot access external smtp servers across a cern firewall, only
socks4
or
>   socks5
>
>   Here is the URL to his archived msg.
>
>   http://rebol.org/userlist/archive/315/656.html
>
>   >===== Original Message From [EMAIL PROTECTED] =====
>   >[EMAIL PROTECTED] on 08/29/2000 03:27:56 PM
>   >Please respond to [EMAIL PROTECTED]
>   >
>   >
>   >
>   >To:  [EMAIL PROTECTED]
>   >cc:  (bcc: Greg Piney/McGraw-Hill/US)
>   >
>   >Subject:  [ALLY] Email and Proxies
>   >
>   >
>   >
>   >
>   >Holger,
>   >
>   >I was trying to show off Rebol and ran into either a bug or my own
stupidity.
>   >
>   >I was trying to send a simple email (one liner) to show some people
>   >how powerful Rebol is. It failed.
>   >After about an hour I found out why.
>   >
>   >I recently changed my 'user.r' to use generic (Cern) proxy. We are
behind a
>   >Netscape Proxy server. This proxy server does not allow mail out.
Mail is
>   >handled by another machine. Most mail clients do not talk to the
proxy
>   >server at all. The reason why I say this is that I changed my
'set-net'
>   >to go to the socks server and all was well. Works like the Champ
that
>   >it is. Something tells me you need a 'proxy/noproxy' setting in
SMTP.
>   >Or, it really is some kind of bug.
>   >
>   >TIA,
>   >
>   >Greg Piney
>   >Standard and Poor's Web Engineering
>
>   terrence-brannon: [[EMAIL PROTECTED] perl-refugee myth-gamer]
>   free-email:       http://www.MailAndNews.com
>   free-usenet:      http://www.mailAndNews.com
>   ; all the above is real REBOL code, believe it or not.
>
>
>
>

Reply via email to