World: r3wp

Ryan, that sounds like just the kind of thing that signed scripts 
should be able to do.

Hi guys. I was going to take the security issues one at a time, but 
Carl and I are talking about getting some kind of file location where 
I can upload a design doc for you to take a look at.

That's probably going to take a couple of weeks, though, as we've 
got some other projects ahead of security.

I'm going to gather your comments and we'll keep those in mind and 
work them into a draft plan which we'll post in the form of a design 
doc in a couple of weeks as I said.

Thanks!

weeks? OK .... just upload somewhere to rebol.net, hidden page later 
...

Just wondering... since the plugin stores a local copy of (simple) 
Reblets in the sandbox, if it had a replicated data-snapshot that 
is used by the Reblet also in the sandbox, would it be possible for 
that code to be executed without a network connection... either with 
or without the browser?

Here's what I am trying to do.  I have a client that has a locked 
PC build (users can't install software).  The plugin managed to install, 
and when network connected was able to find the .r file and execute 
it off the hosting web-server.  However, say the web-server is down 
or network connectivity is unavailable, I'd like the applications 
to still be launchable so the app isn't impacted by an 'outage'.

I suppose I could use Javascript in my HTML file to check for the 
webserver and if not there try to launch the local copy from the 
sandbox.  Any thoughts?

/Desktop uses the local copy wihout network-connection. Maybe the 
plugin does that too?

Or you could download an html-file into the sandbox and the user 
opens it locally by explorer. I guess the plugin would then load 
from the filesystem too. But not sure.

Brock, I'm pretty sure it's possible to do that now. I killed my 
network connection and tested the plugin with a remote file that 
I had already downloaded (it was in the sandbox cache)

Worked fine.

Yes, unplugging works fine.  So if the plugin is running at the time 
of the network connection loss, no problem.  I wasn't however able 
to startup once the connection was lost.

Volker, that may do it, I guess I will need a way to get that local 
html fine into the sandbox, though.  I don't want to install anything, 
but might be able to have the app automatically write that file to 
the local sandbox, hmmm, will try it out.

Its just like the dekstop-sandbox, only on another place. You should 
find that dir by showing 'what-dir. And then just write the html-file 
there, load-thru may do the trick.

Yes, see source of PATH-THRU.  Instead of using DO, LOAD and EXISTS?, 
 use DO-THRU, LOAD-THRU and EXISTS-THRU? They all use PATH-THRU.

Oh, and READ -> READ-THRU

Okay, writing the html file in the sandbox folder worked.  In my 
case, the path to the .r file was C:\Documents and Settings\Brock\Local 
Settings\Temp\REBOL\Plugin\Mozilla\0\public\localhost.  When I placed 
the .html file in the \localhost folder, the html file errored saying 
"Cannot open /C/Documents and Settings/Brock/Local Settings/Temp/REBOL/Plugin/Mozilla/0/wt-selector-2.r", 
so I added the missing part of the physical URL "\public\localhost" 
to the .html file and it works just fine

Maybe using the load-thru or read-thru here would have resolved this? 
 I haven't used those commands much so not certain exactly how the 
-thru commands work and where to use them... I'll read the source 
as suggested by Anton.

No, they are just 'load with download.

would save code, if you did not need to change the file. Then
  load-thru url-of-online-html
would do the trick.

Maybe that could be fixed? That the reblet-url is always relative 
to the folder, be it from url or from files?

I was kind of hoping something like that.  Even better would be that 
if you tried accessing the html file and there wasn't any network 
connectivity that it would by default check to see if the files were 
in the sandbox and you would avoid this all together :-)

Just jump to console and type:

	path-thru http://some-url.com/blah.html

>> view-root

== %/C/Documents and Settings/Anton/Local Settings/Temp/REBOL/Plugin/Mozilla/0/
>> path-thru http://www.rebol.net/afile.html

== %/C/Documents and Settings/Anton/Local Settings/Temp/REBOL/Plugin/Mozilla/0/public/www.rebol.net/afile.html

How about a html-mode in rebol? Where script can be supplied html-encoded? 
Could be nice to show source of reblet. MAybe even could run colored 
scripts.

And one could use html-editors to write. They can handle unicode. 
With some care in parsing rebol could use the &*; as is.

Add a html-field which knows about this, unicode and good integration 
with formatted text.

Don't forget that rich text is coming to rebol at some stage. Then 
we won't need HTML so much.

I mean for im/export. If we can shopw pretty documents, we need something 
 to write it. About html for plugins, that  would be a little demo-feature 
to show code.

I can't wait to be able to click on a ".r" file and have it just 
pop up and go.

I do that all the time by .r-association.

Yeah...not the same...

How does double-clicking on a r file relate to the plugin?

I think he means clicking on a link in a webpage, where the link 
is a .r file.

That works too if the mime for *.r is application/x-rebol . But then 
it is complicated to view source. And it could be nice if *.r would 
run automatically as plugin, without generating an html-wrapper.

Just an update if you're curious what's happening with the plugin. 
We're busy working on it. That security design doc will take more 
time, don't have a ETA yet.

How does double-clicking on a r file relate to the plugin?

Yeah, I can see why this subtlety is not clear…

Let's picture 60-90 million people coming across a .r file on the 
web…
What happens right now?

Reichart, with any downloaded file, including a .swf or .pdf, the 
end-user must first have the application installed on their local 
computer. Therefore, it is the responsibility of the locally installed 
REBOL EXE to register itself as the handler for .r files.

Tell me where I'm missing it. The goal of the plugin is to provide 
an environment for REBOL apps to run within an HTML page. It has 
nothing to do with download.

(in fact, the Acroba or MS Wordt-style MIME-type handler, where it 
inserts its EXE into the web browser, is slow, clunky, and almost 
universally hated by end-users, including myself LOL)

Josh - so you are still working on it? I thought  you were redirected 
to some other project, e.g. help with R3 itself :-)

We're working on a lot of things :)

:-) that is nice indeed :-)

Isn't a security document supposed to be available for comment soon?

what is the current way to get plugin running? moz by copying files 
and ie no 1.3.2 because of certificate?

Tell me where I'm missing it. The goal of the plugin is to provide 
an environment for REBOL apps to run within an HTML page. It has 
nothing to do with download.


This is the second time you have paraphrased what I wrote in a way 
I can't tract.



R: I can't wait to be able to click on a ".r" file and have it just 
pop up and go.
J: How does double-clicking on a r file relate to the plugin?
J: It has nothing to do with download.


I don't know why you mention double click, nor do I know what downloading 
has to do with this.


Perhaps we can get on the same page by simply answering my question… 
when someone comes across a .r file, what happens now?

Graham: Yes, it was. I apologize for the delay. We are working on 
other features first. That security doc may take a few more weeks.

Volker: Mozilla will soon include a better installation experience. 
IE 1.3.2 was released a while ago.