World: r3wp

Google uses Flash and they use javascript's onresize to call the 
flash script's window resize function.

Yeah, it just creates another browser window to pop up in - thought 
I remembered it creating a system window.

Russian Climbing
? I thought the French invented parkour.

French wrap songs, but at the end the guys are speaking Russian (I 
think. Definitely not French, though).

Yeah, it is definitely Russians climbing, but they are doing French 
parkour. The French rap was pretty funny though.

The javascript looks like:
	window.onresize = onWindowResize;
where onWindowResize seems to be defined by the Flash.

Will there be any way to control the browser so that it opens inside 
a rebol window?

this is pretty much the only way to show html

To much here to keep up, just picking " The problem is, then you 
have 5 "REBOL/Plugin" objects in Downloaded Program FIles. Thoughts 
on that approach?":

AFAIK with COM, a CLSID is not bound to a file. You can "serve" multiple 
clasids from the same file.  The idea is, that interfaces are frozen, 
if you need more functions you add another interface. which may include 
the same functions as the old one. So instead of using multiple files, 
you can have  the newest one implementing the old interfaces too. 
But then you have to be exactly compatible when using the old interfaces, 
at least thats the  idea. As firefox clones COM, i guess they have 
a similar feature.

Volker, that is true. But the problem here is not COM interface/version 
compatibility. The problem here is: "Which REBOL binary to load?" 
Very simply put, if a web site relies upon plugin version 1.3.2, 
we must make sure that 1.3.2 -- or a later version backwards-compatible 
with 1.3.2 -- loads on their computer. At the same time, we need 
to deliver critical security updates and other non-breaking updates 
to users in a seamless manner.

I'd like to focus the discussion around one unanswered question regarding 
installation: do we inform the user -- in any way -- of a major REBOL 
+ plugin update (i.e. REBOL 3.0)?

If so, how? Popup/message box? Something else?

Yes, you have to, it is the only way to track bugs, and yey, with 
a popup.

(note: I am referring to IE plugin; I know there may be additional 
support in FireFox, but we're focusing on IE 1.3.3 right now)

I think there's no need to inform the user, unless a web page needs 
it.

Reichart, I don't understand what you mean. Can you explain in more 
detail what you mean by "track bugs" ?

If there is a problem after an update to a plugin, and you do not 
notify the user that there was a problem, there is no way for them 
to know what caused the problem, and they will waste thier time trying 
to hunt it down.  If you simply notify them when things are updated, 
they can connect the problem to the closest issue.

Ok, that sounds perfectly reasonable, but it seems we read the tense 
of Josh's "update" differently. Josh, are you asking whether to inform 
the user of the availability of an update, or of the completion of 
an update ?

Wasn't the plugin going to run REBOL 1.3.* and 3.0 in parallel, depending 
on which generation the script requested? If that is the case, whi 
would a user of a 1.3.* script need 3.0? Soon enough they will be 
running scripts that need 3.0 - we can tell them then.


On the other hand, the plugin itself will need updates too, and maybe 
we can install 3.0 then for future reference.

Anton, that's a good question. My first thought was to ask before 
starting the download, then ask again after the download is complete 
and we are ready to install.

Brian, that was what we talked about last night, but I'm still tossing 
those ideas around. not sure yet.

That's cool.

The problem here is: "Which REBOL binary to load?" 

Thats why you put the clsid in the webpage. Thats understand by the 
browser as: get interfaceclsid and tellit "run script". Other clsid, 
other interface, run script as 1.3.2, 1.3.3, ..

Yes, but the problem is: five versions means  five different entries 
in the user's "Downloaded Program Files", which is hardly a seamless, 
clear experience. That actually was our original thinking, and it's 
how we implemented the betas 2 years ago.

We're reconsidering that approach, however, because it's not as seamless 
as the Flash-style experience, which is: latest version runs everything. 
So you don't have to worry about which REBOL you have installed, 
you just have the latest one and everything is fine.

I'm open to suggestions and feedback though on which approach is 
best. The first, side-by-side for everything approach, is how we 
started, and we can continue that way if it makes sense and is best 
for the customer. thoughts?

Means 5 different files?

in some download-folder?

But i would do what flash does anyway.

Should we inform the user is a new update is avalaible?

I think this should be configurable for compatible updates. I guess 
some people might become nervous, if the plugin connects to the rebol.com 
site on every invocation. Even it is only looking for updates, well, 
you'll never know ...

On incompatible updates: The user should get a message along the 
lines: "You have installed the Rebol 1.3.4 plugin, this website needs 
the 3.0 plugin" of course only, if that is true.

I would ask for "download and install" for user convenience. Ver< 
few people would want to download and check the binary before installing 
it. Maybe you _could_ add a checkbox to "only download".

Well, I hate popups, but I hate not getting inmportant info even 
more ... so, I start downloadinf a webpage, while this page is loading, 
I open another tab, and work on this. Now I return to my first page 
later, and I find an embedded message "We're sorry, you first need 
to download the new plugin version" would make me go crazy :-) So 
I would like a popup in this case. 

Well, when there is a new security update, for maximum security, 
the plugin should stop to work until the user has answered, wether 
he wants to update, or go with the old plugin.

I systematically hate everythings which "calls home"  even for updates.

this must be a setting, even if it should be in the user's interest 
for it to be automatic.  simply because it raises trust.

in the least, ask -before- checking or  allow through options to 
disable automatic updates.  simply cause automatic updates can break 
things which where working.

How long is the 1.3.* plugin going to be in use before the 3.0 plugin 
is out? If it isn't that long, can we just plan for its obsolescence?

the fact that they are considering the 1.3 plugin I think says it 
all.

Josh, I prefer: ask before download + install, notify afterwards 
of success or failure.

And the side-by-side approach is good, as long as each version is 
clearly indicated.

I'm curious as to how many people are actually deploying the plugin 
currently?

Or, is this a chicken and egg situation?

I agree with Maxim. Most people out there in the world don't have 
any reason to trust Rebol or Rebol Technology. It might be just another 
spyware company for all they know. Why would they (initially) want 
to allow an automatic software corridor into their computer ? It's 
an issue of trust. First let them try it out, then when they like 
what they see, allow them to enable more automatic security updates 
if they want.

Josh, to be precise, that's:  "I prefer: ask before (download + install), 
notify afterwards..."  - where "download + install" is one operation 
from the user's point of view.

So can we store a flag somewhere in the system? 
	automatic-security-updates = true / false;

I agree with Maxim as well, there needs to be UI somewhere to stop 
automatic downloads.


With that said, is it possible to clean this whole thing up and reduce 
it to one place where you either have what you need or you don't.


Using Adobe Acrobat as an example, they have one plug-in interface.

When you download stuff, it asks you if you want any of the other 
modules Adobe has for you.  In fact a close friend of mine created 
one of those modules (Atmosphere), which is funny that Adobe's interface 
even asks if you want this, since almost no one know what Atmosphere 
is.


So a single consistent dialogue should pop up with something like 
this:

You have:

Rebol command 1.3 for OSX
Rebol view 3.0 for OSX

New modules that are available:    

[_] Rebol view 3.0 for OSX
[_] VID2 interface Alpha for OSX


[X] Always ask before downloading

[Skip] [Download all now]

Hi, I am back after one week trip to Germany, so kind of difficult 
to catch-up with all that discussions and possible aproaches ....

But I will try to express my opinion here for those various topics:

Anton - no need to run separate RAMBO imo. Just add another product 
category - browser-plugin .... should be enough to be able to filter 
out plug-in related topics .... I like RAMBO - simple and not bloated 
....

As Graham or someone else suggested - let's sort out few issues first 
- UI, installation, integration ....

1) UI - we are not Flash player, we will likely produce real-life 
apps. So - do we give up right mouse click for configuration options? 
What if you will have your own one in your app? OTOH imo there NEEDS 
to be some UI for setting some parameters! Not everything which comes 
to my mind can be hidden from user. The ones which come to my mind 
- do you want to check for updates? Once a month, week, daily, Automatic 
downloade newer version? Ask, download. Use newest version if app 
does not specify its requirement? (maybe not needed, just an example 
of what could be configurable). Proxy settings .... List available 
version, provide uninstall button, etc.

to add to UI topic - should we add default border to the area plug-in 
is supposed to be? Should we add kind of app-bar, where configuration 
could be accessed? (could cause problems with app-area calculation). 
Or maybe to make it sliding, e.g. when you stay for more than few 
secs with a mouse over the top 5% of the plug-in app area? (could 
become annoying) - just throwing ideas around ...

2) Installation - I like several versions installation - IIRC even 
Java can coexist? I use it with mozilla - I run Mozilla suite or 
Seamonkey, various versions from various locations - they do share 
profile - settings, sandbox .... 'Needs field could work for us too. 
If the app specifies it, try to locate particular version. If such 
version is not available, display dialog, where you preselect latest 
version and provide with list-box, with ability to manually choose 
from available versions ... and "run" button ....