World: r3wp

why not a sandbox for anonymous, Brian? as long as its is the only 
place, lock down no read or write outside it. Widgets, flash, google 
earth etc all allow state & cache in sandbox

apple and konfabulator widgets would not be as numerous if signing 
was required for scripts

Henrik, if someone wants to run an anonymous browser script in /View 
they are welcome to try, but the browser integration won't be there 
so the script may not work.

something else entirely: should there be a more REBOLish way to access 
the browser DOM tree?

(I think it would be very cool to have a DOM tree browser written 
in REBOL)

Anonymous scripts should be able to read through the browser cache, 
at least for files from their own site, but should assume that those 
files won't necessarily persist beyond the browsing session. You 
don't want to give them a sandbox that doesn't have its space limited 
by the browser's existing facilities, for security and privacy reasons. 
You definitely don't want anonymous scripts to store more than cookies 
on your systems.


The guideline you should set for default behavior of anonymous scripts 
is to limit it to the activities that would be OK for deliberately 
malicious code to do. Assume that all anonymous code is out to get 
you until proven otherwise. This is a browser plugin you know - it 
will be used in banner ads.

Konfabulator widgets are more comparable to regular reblets running 
in View. Just because they are implemented in XML/CSS, doesn't mean 
they are held to the same behavioral standards as web pages.

Yes, a DOM tree browser would be very cool.

and "sell" it to the AJAX developer community :-)

I'm OK with a virtual sandbox that gets deleted on browser shutdown. 
We don't want REBOL to be used as a vehicle for persistent, hidden 
tracking data to be put on users' computers. I want a browser plugin, 
but I want one that even the paranoid would be OK with installing.

As long as the virtual sandbox can't be used to generate data files 
that can fill the hard drive (or even be written to it), it should 
be fine.

BTW, someone needs to consider the new plugin activation that Microsoft 
added to get around that BS patent, and what effect it will have 
on the IE browser plugin.

Hello Josh! I have one request. Try to run this:

under IE:
http://www.rebol.cz/~cyphre/plugin-ie.html

under Mozilla/FF etc.:
http://www.rebol.cz/~cyphre/plugin-moz.html


Drag the green box using mouse and try to move it quickly over the 
screen. You can see the time lag when the green box is updating the 
position.

Now try this from normal Rebol/View console:
do http://www.rebol.cz/~cyphre/plugin-moz-test.r


You can see there is no lag and the green box is updated very quickly.

Do yo have any idea what could cause this difference?

my specualtions: 

1. Are you always blitting the whole screen in the plugin versions? 
This could cause the slowdown as there should be updated only the 
part with green box on the screen.

2. Could be the slowdown cause by different(higher)  amount of mouse 
events which are pumped from browser to the plugin?

cyphre, try resizing the browser window to fit the plugin. it doesn't 
speed up, so it might be something with mouse events

even making the window very small doesn't help

yes, it looks more like event overflow.

I have two wishes re. Rebol and the browser -- 1) to use Rebol as 
a language replacement for JS, and 2) to be able to launch Rebol 
scripts intelligently.  The importance of running Rebol as a Flash 
replacement is a distant third.

2) I have brought up before -- a plugin could intercept and interpret 
a Rebol script, using the header metadata to create a launch 'page'.

1) is likely a pipe dream without ubiquity.  As messy as JS/DOM is, 
it is a standardised language that most if not all modern browsers 
adhere to.  That it is standardised allows Ajax developers to depend 
on it (which was not the case when pre-standardised implementations 
ruled).

well, you can minimize the use of JS, but not entirely get rid of 
it. I'd imagine that someone could conjure up a library that translates 
common DOM access through JS to rebol code

2) really should be the focus.

For as long as I've been creating Reblets, the pain is in exposure 
-- explaining to people (inc. parents) how to actually launch them. 
 An intelligent browser launch mechanism would minimise that.

if this is done right, the plugin should be just as easy to install 
as flash

2) Past disussion mid-November in 'Advocacy' group.  Mockup here: 
http://www.ross-gill.com/arran.html

Henrik: is Flash even installed any more?  Seems it's distributed 
with the OS nowadays.

That should read: does Flash even need to be installed any more?

hi all, thanks for your feedback. good ideas.

there are issues with it under linux at least. Macs ship with it 
as standard. I think you still need to install it under windows, 
but it's fairly easy under IE

I've made a couple of checklists:

 Plugin 1.3.2 Mozilla bugs -- bugs you see in the pre-alpha of Mozilla 
 plugin.

 Plugin 1.3.3 feature reqs -- feature requests for the next version 
 of the plugin.

also the empty boiler plate should be more refined to display that 
this is a rebol plugin area, rather than just display the version 
number

Please post your bugs and feature reqs there....one bug/feature request 
per item. Repro steps and target platform (for bugs) and clear descriptions 
with examples  (for feature requests) help :)

Here's my thinking on priority on the plugin project:

 1. IE plugin for 1.3.2 -- we'll have this online within a couple 
 of days.

 2. Mozilla plugin for 1.3.2 -- features equivalent to the IE plugin, 
 although we may need to chop a few things out (do-browser for instance).

 3. IE plugin for 1.3.3 -- the most important new features we can 
 include in a relatively short time-frame release.

 4. Mozilla plugin for 1.3.3 -- again, features equivalent to the 
 IE plugin, but this is equal priority with the next item.

 4. IE plugin for REBOL 3.0 -- new features that will ship with REBOL 
 3.0 (multithreading/multiple instances per browser, etc.)
	5. Mozilla plugin for REBOL 3.0 -- features equivalent to IE

WRT to the 1.3.3 release: I'm going to need your help on sifting 
through all the "noise" (i.e. everyone's opinion about we should 
have or not have) to drill down to the features that are absolutely 
necessary for this release.

If anyone has ideas on how to do that, please let me know (maybe 
voting for the top features? not sure).

do-browser goes out? that means no DOM access in the mozilla version?

We need to investigate it. On IE, this is accomplished through a 
COM Interface to the browser object (via IDispatch), and then we 
call the method execScript on the IHTMLWindow object, passing the 
string of the code. But on Mozilla, there is no such COM interface, 
so we need to find if there is an interface available to the plugin 
to pass JS code.

If someone wants to investigate it, go for it.

I want to bring up a new issue: installation.

With the current plugin release, new versions require uninstalling 
previous versions, because of the IE plugin architecture (it is finding 
the existing plugin on your computer, so it sees no need to download 
a new version).

Now, that's a real pain for users. There are essentially two solutions 
to this problem:

1) Release a new "ID" for the plugin, so 1.3.3 would install side-by-side 
with 1.3.2. The problem with this approach is that the user now has 
a new plugin object in their Downloaded Program Files for every release 
of the plugin, which looks strange....not to mention problems such 
as: "does this web site support plugin version 1.3.2 or 1.3.3?" how 
do I know which version I have installed?

2) Build an automatic updating mechanism into the plugin, so it will 
check for new updates, prompt the user if he or she wants to download 
those updates, and then install on-top of the previous installation.

(2) is what I am leaning towards, and that is also the approach Flash 
takes. It involves making some changes to the installation architecture, 
developing an installer program to drop the files over-the-top of 
the previous files, and writing some REBOL script to check for new 
updates.

A little work, but I think it is worth it. The alternative is a very 
confusing experience for users.

it's definitely worth it. if it takes longer than 1-2 minutes to 
install then most users will drop it.

(note: The REBOL standalone EXE currently does something similar, 
but the difference is that the plugin doesn't know where it is installed...yet 
(so it can't drop the files over the old ones), and plus, the installation 
process for updating 2 DLLs is different than updating 1 EXE).

Yes, the installation will have to be quick. That's not a problem 
though, as we can download the files in the background (similar to 
what Flash and Acrobat Reader do).

Thoughts?

not just that, but there should be a ridicoulus minimum amount of 
instructions to install it. such as: 1. go to this site to observe 
the installation. 2. click here to test. and that should be it. I 
know that's very difficult to do, but it should be the goal.

(I want to change the above priority list. Mozilla 1.3.2 and IE 1.3.3 
are equal priority, pri 2)