World: r3wp

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)

Here's my thinking for the installation process:

 1. REBOL script within plugin checks for new version. If new version 
 exists, asks user: "There is a new version of REBOL/Plugin for Internet 
 Explorer. Would you like to update?" [or something like that]
	2.REBOL script within plugin downloads updater EXE.

3. REBOL script within plugin launches updater EXE, which asks user: 
"Would you like to install REBOL/Plugin? Note: Your browser will 
have to be restarted."

 4. Updater EXE closes browser, copies files, and re-opens browser 
 to the page the user was at.

5. new plugin launches seamlessly and runs the old script.

This, of course, assums that new plugin versions will not break old 
REBOL code.

(or I should say: new REBOL versions will not break old code)

I think there should be a way to suppress console output when a script 
crashes

console = popup window and some users hate those

Henrik: thank you, please post it on the 1.3.3 feature req checklist.

done

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

Well, we can throw it into Qtask, let everyone log any task they 
want, and then you can assign them priorities.  This is what Qtask 
does.

hi, thank you for updating this plugin !-)

but like the first plugin version do not forget to take proxy configuration 
of IE or FireFox and the bypass-proxy input !!!!!!

like this we will be ok to use rebol/plugin in intranet behin a firewall...... 
thank you again

This is I think an important feature - to be able to use the browser 
to distribute your rebol applications across private network.

Agreed.

Security settings often prevent users from installing applications 
.. so a browser app makes it easier for admins to distribute an application.

For plugin updating, you could make the minimum version a parameter 
and have the plugin update if the requested version isn't installed, 
or fail if the requested version doesn't exist.

As for things like do-browser, it would be nice if the copy of REBOL 
called by the plugin could be passed some callbacks to which it would 
delegate some basic functionality like requesting a local file, proxy 
settings, do-browser, etc. This would allow the plugin to better 
integrate with the browser's existing behavior and security infrastructure.

If the REBOL library's runtime environment could be extended with 
arbitrary routines defined in the wrapper plugin that would make 
things like do-browser even easier.

By the way Josh, the security discussion we were having last night 
wasn't noise. Without the security restrictions discussed above noone 
would be able to safely install this plugin and allow it to run scripts 
from any but the most trusted sites. This is important.

I messaged you privately with my concerns.

I agree with Brian wholeheartedly.

thanks for the feedback. i apologize if i conveyed the idea that 
security discussions are noise. What I mean is that I don't have 
the bandwidth to sift through pages of discussion and build the plugin 
at the same time. So, for my sake, we need some kind of itemized 
system where Carl and I can tackle the issues one-by-one.

And -- yes, I need to read through the conversations, but a free-for-all 
format (that includes bugs, etc.) doesn't really work for me. Maybe 
a checklist, or perhaps, Qtask (mentioned above)?

Maybe another RAMBO database ?