World: r3wp

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 ...

because what you propose is imo big change, and I am not sure it 
is good to introduce it for last R2 incarnations ...

Well, you tell me. Here are your options:

 1. Minor fix to get-net-info that reads correct registry values. 
 Does not handle auto-config, NTLM, or Kerberos.

 2. New refinements to 'read and 'write that use Win32 Internet API 
 to download and upload HTTP/FTP files. Uses whatever is supported 
 by the OS, including auto-config.

Would you prefer (1), (2), or both?

I have to have an answer fairly soon, so everyone who reads this, 
please chime in asap.

Actually, I realize that there is no problem with get-net-info with 
manual-config proxy servers. So, scratch (1) off the list above. 
The question is very simple now: Do you want a solution along the 
lines of what I proposed in #2 above?

both ... what about other platforms, Josh ... how is that with Linux 
for e.g.?

We're only talking about Win32 here.

Refinements are ok, because it can be platforms specific code ... 
but I said enough, without expertise, so I will wait for others to 
express their opinion ...

To clarify: I made a mistake above. There is nothing in get-net-info 
that needs fixing. The single question is: do you want a Win32-specific 
refinement that changes the read or write to use the Win32 HTTP/FTP 
API, and consequently enables full proxy support?

get-net-info needs fixing by its own - it looks at incorrect registry 
keys imo. Apart form ntlm, kerberos and autoconfig proxies, it would 
work, so imo it would work in 90% of cases as sufficient ...

Which registry keys are incorrect?

JoshM as long as the big picture includes the ability to authenticate 
by MS Proxy then I'm good.  This can allow me to make a plugin that 
can reach our printers via the network using their web interfaces.

Software\Microsoft\Windows\CurrentVersion\Internet Settings? Dunno, 
I don't remember ... I posted is several times already and I would 
have to inspect it ... just playing with proxy settings revealed 
that code is incorrect ..

Paul, you are OK with this support only on a Win32 client, and just 
in read/write?

Currently the lack of Proxy support that is compatible with MS Proxy 
severely limits what I can do with it in our environment at EDS.

I would like to proxy any port but I think that http, ftp is good 
for this round since the MS Proxy permissions would have to allow 
the rest anyway

Pekr, you told me before that the problem was that it ignored auto-config 
settings. But I'm already saying that there's no adding auto-config 
support to get-net-info. If you see something else that is broken 
with get-net-info, please post it. (it seems to work great here)

Paul, thank you for the feedback.

Sure thing Josh.

I want to make it clear that we are not promising these refinements 
or anything along those lines.. We may nix the whole idea. We just 
want to get your feedback on the idea. Would you like refinements 
that use the Win32 HTTP/FTP API, including proxy support?

I would prefer os-level reading. That may also fix Brianh's problems 
re illegal downloads, i guess this data is cached in browser-cache 
of ie. Maybe read-thru could be changed to use that instead of sandbox. 
Easier to know what is on the system.

Re crosssplatform: i see no problem. if i read-thru url, i want that 
contents. it is not interesting how that works technically. (Except 
for protocoll-related hacking, but i really do not need that for 
the simple solution)

Volker, yes, OK....got it. But you won't have full proxy support 
on any other platform (for now).

Is that OK?

Said it wrong. os-level means #2,

where the reading is done completely by ois.

Yes, I understand. But we're not talking about OS-level reading on 
Mac or Linux.

But if you have the refinements that could be done.

Yes, at some point in the future.

Yes. Well, linux-rebol is somewhat restricted usually..

And i guess you find similar apis on this systems.

Yes, true.

OS/X would be more important. But i guess it has similar apis too.

On Linux gnome and kde have some layer to allow urls everywhere. 
I guess they have the neccessary apis  too. But that is  even more 
later, maybe with R3 when such parts are open.

Hmm, for reads we could 'call wget, at least for reading.

proxy is usually global under OSX, so that should not be hard information 
to get

Have we got 1 Stability and 2 Security yet ? We have jumped to 3 
Proxy, even though everyone agreed to Josh's ordered list.

2. security: signed scripts

And with that #1 may be not that important in some scenarios, so 
could be perfected later?

Eg a company could run the plugin internally, allow only own scripts. 
Then proxy is a showstopper and stability can be worked around by 
the scripters.

That may help some projects to get started.

No, I think instability means crashing the browser, not being able 
to install the plugin at all etc.  I followed the installation steps 
and it didn't work for me. (I should spend more time analysing why). 
But that means I can't join in with testing and be at the same level 
as everyone else here.

Thats true, my misunderstanding.

ok :)