World: r3wp

Yes. Confirmed. Josh is working on better way to obtain the proxy 
information, according to MS methods.

Sorry, although 3.0 is highest priority, we are "multiplexing-in" 
a few other tasks.

Just so you know for sure: we do plan to make a 2.6.3 (1.3.3) update 
to fix various R2 bugs, including a range of OSX related issues.

Gabriele is the main contact regarding the R2 priorities.  So, you 
must talk to him if there is a critical bug that you need scheduled 
for fixing.

It certainly makes sense to complete those things that can be readily 
done ...given that R3 may be months away

The desktop is nearly dead anyway.

Google and Microsoft are battling for ownership of the web space.

Rebol has a chance now that paradigms are shifting into general acceptance.

that the desktop is being superceded by internet applications.

But we need to be there in less than half pie fashion ...

We don't want to be crippled by lack of SSL and other show stoppers

Hi.  location   not work in Firefox  1.5  .  try it  code :    do-browser 
 "location='http://rebol.com'"

Micha: Try this: do-browser "location.href='http://rebol.com'"

Plugin "completion" project: As Carl said, we are going to take the 
steps necessary to make a R2 "complete" plugin.

Based on your feedback, I've divided this project into three areas:
	1. Stability (no bugs, Win2k support, etc.)
	2. Security (signing, program limits, etc.)
	3. Proxy (correct proxy detection)


Is that accurate? Do you think that after addressing those three 
areas, the plugin would be "complete"? If not, what other areas do 
you think we need?

1. IE 
2. Firefox
3. Safari

Opera

But yes, Josh, it seems like correct order. I give my vote to proxy. 
Dunno how many folks work in companies behind the proxy, but because 
there is not user.r by default, nor there is some abilitiy to launch 
desktop, the plug-in should do as much as possible, in regards to 
correctly detect proxy ...

Josh, that looks good to me.  Proxy would be good.

Josh, I believe the Proxy support is really needed and obviously 
that could be used in REBOL3 for universal use.  I hope you implement 
both kerberos and NT LM Authentication.  I know that Doc Kimbell 
already has a tested Proxy implementation using the NT LM Authentication 
on his website.

If I recall the Kerberos is the default authentication on newer MS 
operating systems and NTLM is the older legacy authentication method 
that should be incorporated to support a more diverse environment 
where Win9x  and NT 3.5-40 machines might be in use.

I know in my environment where we work with multiple customers with 
thousands of workstations in interconnected networks and extranets 
we definately need the proxy support.  We have so much proxy authentication 
going on between internal networks due to acquisitions where segmentation 
and security are still sensitive concerns.

Proxy: I've broken this sub-project down into two areas:

 1. Detection (auto-proxy, manual proxy, etc.) -- obtaining the correct 
 proxy server address for a given URL.

 2. Authentication (NTLM, Kerberos, etc.) -- authenticating with the 
 proxy server

Are there other areas you see related to proxy support?

not known to me .... but I know only a little about it ....

For NTLM authentication, isn't there some OS API to do that ?

I can't imagine that each program using Internet has it's own NTLM/Kerberos 
authentication scheme!!

Yes, I'm looking into both OS API and native methods.....

Question: On these systems that need full proxy support, are you 
running the latest OS? (i.e. WinXP SP1+, Win2k3, or WIn2k SP3+)? 
If so, there is OS support in those systems that may make this significantly 
simpler...

as for me, yes, no W9x machines ...

Am I correct in assuming that the majority of these proxy scenarios 
are just downloading HTTP/FTP files? Is there a case where you need 
upload support through proxy as well?

I am not sure what is proxy, but in our case it is kind of web cache 
... we have squid here - it looks at its local cache, and if the 
file is available locally, it is served to you by proxy, not downloading 
it from web once again ...

OK. I'm thinking about using Win32 HTTP/FTP upload/download API functions, 
which use the proxy settings set in Windows.....

what for? just to get config?

It's not exactly the REBOL cross-platform way to do things, but it 
seems to make sense for this Win32-specific scenario......

No, getting the config won't be necessary. There is full support 
in Win32 to download and upload files via HTTP and FTP, and these 
API functions automatically use the Internet Configuration in Tools->Internet 
Options, which includes proxy.....

yes, but I just don't understand, where http/ftp download/upload 
in Windows is related to rebol networking?

I need to run this by Carl, but my thinking is along the lines of 
a new option to 'read and 'write that says "use win32 HTTP/FTP API". 
If you choose that option, you get full proxy support in Windows....

With this approach, we're not building full auto-config/NTLM/Kerberos 
proxy support into REBOL, rather we're utilizing the OS API resources 
to do it all for us.

but does Windows http/ftp API limit rebol free socket capabilities 
or not? :-)

otherwise understandable, although - sockets are sockets, and imo 
similar everywhere .... I prefer the rebol way, cross platform ... 
why is that so difficult to read few registry keys and decide? The 
only problem is the proxy auto-configuration script, which in fact 
is - javascript ...

You would have only the capability of HTTP and FTP requests via Proxy, 
we're not talking about proxy-enabling the whole network stack. I'm 
not sure that makes sense anyway (i.e. if the cache server serves 
you a cached page, you're not going to communicate with the actual 
server anyway).....

The problem involves not just the auto-configuration script....there 
are also options to use multiple proxy servers, exclusion lists, 
etc. In addition, there are custom authentication schemes, i.e. NTLM 
and Kerberos, that REBOL may not fully support natively. With this 
approach, you receive full support for all of the above.

well, I let gurus to decide, maybe I am not correctly understanding 
the issue ...

ok, and what is the option to support proxy in custom build protocols? 
Will it remain?

The problem is that today REBOL is doing everything itself. It is 
making the socket connection, sending the GET command, etc. In the 
process, it has to know everything about the proxy settings and do 
everything natively.


I am proposing adding new HTTP/FTP support that uses the Win32 API. 
No more socket communication within REBOL -- instead, Win32 does 
everything, including interacting with proxies.

(When I say "No more socket communication", I mean that these options 
will not use the REBOL networking stack)

I hope that's clear.

so native raw rebol socket low-level communication will be still 
possible, right?

Sure. But not with this proxy support.

Maybe we'l fix get-net-info and you can have basic support, but no 
autoconfig or anything like that.

ok, that would be imo better ...