World: r3wp

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 ....

3) Integration - the toughest part - first - old plug-in way of integration 
was not optimal. REBOL's code  of 'get-net-info is outdated and broken. 
First thing is to get proxy info automatically, if possible, but 
still allow it to be settable. Most corporate users do use proxy, 
without it, plug-in in non-existant product for corporate environment 
imo. Why to allow manual settings? Well, dunno how many companies 
do use it, but our company does :-( ..... "use script for proxy configuration" 
- and the script is JS code, which browser can interpret, but not 
rebol itself, so we need ability to set it manually


... or - second point and probably the main point from the architecture 
pov - do we allow what rebol allows? Do we allow our own networking, 
or will we allow only to tunnel via browser? One one hand, we would 
get https, on the other hand, if we limit it, we are not talking 
about rebol anymore, but sligthly different rebol based product. 
As for me, I am not able to see all the security related concerns, 
so I let it to others here ...

As for simplicity, I do agree it all has to be as much automatic 
as possible. In IE is is better than in older Mozillas - you just 
click the plug-in area and it gets downloaded and started with the 
page refresh, not even browser restart is required IIRC ...

.... on more point to UI - I really don't know, what to do with pop-ups. 
I suggest, for REBOL 3.0 View, to have rebol based windowing system, 
not to use separate native OS dialogs, or we are doomed here. Each 
view/new means new window, and ppl who are used to add-block will 
feel uncomfortable imo ....

Did anybody try Cyphre's http://www.rebol.net/plugin/moz-1/cyphre-demo.html
in Mozilla? In Seamonkey I get sligtly different results than when 
it is being run in View directly ... e.g no sound, the wheels (second 
sequence) are blinking strangerly, there some some white-page breaks 
with nothing displayed, whereas in View there is some text ... (IIRC 
e.g. Sea Dream in the beginning is missing in browser)

Pekr - "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?"


I have no idea what you just said here.  Flash is used to make billions 
of dollars worth of complete stand alone product, as well as complete 
websites and small stand alone application that are delivered over 
the web.  


And they can completely control the right mouse button's access to 
a menu.


So, actually, we are JUST like a flash player.  In fact "flash player" 
is a misnomer, since it moved way past "playing" and into complete 
UI years ago.  Rebol and Flash really could not be any more similar.

Reichart - it is really strange you really can't understand, what 
I am talking about ;-)

go, find whatever website flash plug-in part of website, press right 
mouse - you will see menu for controlling flash script itself ... 
that is what I am talking about - you will find flash player related 
menu, not app related menu. And IF context menu is supposed to be 
under MY control, I can't guarantee you, that there will be SINGLE 
item left to configure rebol plug-in itself .... so, for me, Flash 
context menu is nearly nonexistant = used for Flash player itself, 
not for the app ...

... and if I understood it well, we are looking for unified way of 
how to access rebol plug-in configuration .... so my concern was, 
that if someone suggested right-mouse-click here, it could not be 
regarded being safe, because app developer can request such functionality 
for app itself, and in such case, there will be no way of how to 
access it ...

Reichart - and you imo overestimate Flash's importance - they can 
be milti-whatever company, yet I would have to see some noticed real-life 
app someone uses in corporate sphere :-)

pekr, I sort of agree with you, but it's impossible to ignore how 
widespread flash is, not for apps, but for animations, stylish pages 
and now video with youtube and video.google.com. I actually think 
the easiest way to watch video is through flash.


The point is though not really what flash does, it's how it gets 
spread. I think REBOL/Plugin should emulate that behavior as close 
as humanly possible. people who have installed flash, would know 
how to install REBOL/plugin (visit a specific site, wait for download, 
click 1-2 buttons, done). That initial "installation experience" 
is incredibly important for the widespread use of REBOL/plugin. If 
people can't use it within the first 1-2 minutes, they'll forget 
about it and move on.

The problem that REBOL/plugin needs to solve is that which current 
Java applications are only moderately successfully solving. They 
are slow, Java doesn't always install that easy and the level of 
interactivity offered by Java doesn't seem to make developers use 
it for other than specialized applications.

a problem I've noticed about flash is that performance is very uneven 
under different OS'es. Macromedia...oops Adobe :-) might not prioritize 
the OSX version as highly as the Windows version. Flash for OSX is 
absurdly slow compared to other graphics engines for OSX. It alienates 
the OSX users because of those issues. REBOL/plugin may not necessarily 
suffer such crossplatform issues.

Henrik, Reichart - there is no need to reply to flash being widespread 
or not, that all is misunderstanding. I did not start talks about 
multi-billion kind of stuff ;-) My only care and point was - how, 
UI wise, do we allow to invoke rebol/plugin configuration, so let's 
please stick to it :-)

would we allow to invoke any configuration at all? what's to configure? 
SMTP settings? Possibly sound. this makes me think of another thing: 
would we want to be able to send mail through the plugin? it would 
be very easy to create a spam bot this way.