World: r3wp

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 :)

That is the right order. I had some free time today and was investigating 
the issues involved with the proxy project, hence the discussion. 
(we may develop this slightly out of order anyway, because Carl is 
in France for a few more weeks)

Anton, BTW, what system do you have?

Firefox on WinXP

Firefox 1.5.0.4

Will this affect things like BEER?

ie. enable it to work?

beer is not about http, so hopefully not. On one hand, we would get 
proper http/ftp, maybe faster, more robust (authentication), on other 
hand, if my understanding is correct, it will be kind of hardcoded 
in rebol kernel ....

as my understanding goes, raw socket remain, so if someone wants 
his http scheme, he can still program one in rebol ....

btw - Beer does not use http, no? It uses plain tcp IIRC ...

yes

Will this proxy support allow https?

imo not ... proxy is not about security imo. Https requires ssl inbuilt, 
and it is only in Command imo. But if you mean that security should 
not be luxury and it should be provided by default in all rebol versions, 
then I am with you :-)

Not sure about this.

If we have access to the win32 http api, we should get https as well...

and not require command

I agree, if you can't use plugin under HTTPS, then it's largely useless 
in secure environments.

win32 api https
 http://blogs.msdn.com/ie/archive/2005/10/31/487509.aspx

WinInet.dll offers a Win32 API for http, https, and ftp downloads 
combined with other API for caching and parsing.  It\u2019s a very 
popular binary, and in addition to being part of the IE platform, 
is widely used in Windows client applications for its Networking 
services.

this one?

Looks good.  Does cookie handling as well.

makes it easier for us to pretend to IE.

These proposed refinements would use WinInet, and consequently, support 
HTTPS.

But no promises that would be available in a free version of the 
plugin -- need to check with Carl on that.

Josh: I guess this could be plugin-only and either replace read-thru 
etc. with a native or provide new port schemes (probably the former 
is much easier). if for some reason it's not possible to make the 
native read-thru compatible with the old mezzanine one then there 
would need to be a new name I guess, but I'm not sure Carl would 
like that (no more cross-platform, although the plugin is already 
single platform rigth now so maybe this is not a big problem for 
r2 and can be solved in r3)