World: r3wp

For that matter, is it possible to specify the size of the client 
area relative to the page size, have it resize with the page, and 
have the REBOL layout inside handle the resize as if a View window 
had been resized by the user?

Adrian, no, that's right, you can't relocate windows.

Brian, I notice the Google Videos do this, don't they ?

yes, I believe they can

Aha! A good reason to post this crazy video:

Russian Climbing:

http://video.google.com/videoplay?docid=515642196227308929&pl=true

That's a great video - was totally amazed the first time I saw it

Looking at the source....

I belive the Windows media player can also be made to come out of 
the browser page (I don't mean full screen)

At least I'm pretty sure I've seen the latest version do this

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.