World: r3wp

regarding security: so we need a list. i.e. change #1: disable xyz. 
change #2: make xyz a prompt that looks like this. etc.

I've added a few entries to your 1.3.3 checklist based on reading 
these discussions.

http://www.rebol.net/cgi-bin/rambo.r

Guess who :)

okay :) i'll talk to Carl. i think he said no to RAMBO once (above), 
but maybe we can get something working.

Brian: thanks!

Well, I can summarise the security proposals as discussed here and 
post them to your private message area if you prefer.

In between working with Gabreile on parse extensions, of course.

I mean Gabriele.

Can you just use a checklist item? maybe post them in this format:
	Title: Disable xyz.
	Description:
		<long description>
		Priority: <1-4>
		Benefits (what we gain): 
		Tradeoffs (what we lose):
		Why it's worth it:

that's just an idea. i'm open to other formats.

And don't forget those of us who want to use the browser as a delivery 
mechanism for fully empowered un-castrated Rebol applications.

Sure, if you want. I'll edit the security entry I already put there.

Regarding timeframe: I'm still in the middle of developing this new 
installation system which will allow automatic updating. After that, 
we'll move to whatever you guys think is next on the priority list. 
Maybe security? :)

Don't worry Graham, we already adjusted for your concerns yesterday.

Graham: okay. that's the whole licensing/encryption/pro features/etc. 
issue right?

That partial encapping, signed and encrypted scripts proposal.

No .. I think people are frightened that Rebol might be used by some 
mafioso types to damage/hold to ransom your pc.

Right. It will be on the list, but may not make it until REBOL 3.0. 
That seems a little tougher to do. TBD.

Like Lethal Weapon IV

Which it will.

1. User right-clicks existing plugin in browser window for context 
menu, chooses "Check for newer version of Rebol Plugin"
2. Plugin checks for newer version

3. if newer version -> "Would you like to install newer version ?" 
4. if "yes", download and install.

5. "Would you like to remove the older version (you probably don't 
need it now) ?"


When there are multiple versions installed there could a menu option 
to activate one of them.


!!Updater should not close the browser. It should suggest to the 
user to close and reopen.

Anton: So you're proposing multiple versions running side-by-side?

That's an interesting thought. Can you explain why?

If possible. I understand it might be difficult with files being 
overwritten etc.

The newer version make break older code that the user may be relying 
on. "Thanks a lot, updater!!"

I think that major versions should be installable side-by-side, and 
minor versions autoreplace so that security fixes can propagate.

Like Java.

Okay I see. So, REBOL 1.3.2 and 1.3.3 autoreplace, but REBOL 3.0 
installs side-by-side?

A minor security "fix" can also break older code.

But better done of course.

And then we promise not to break old code with the auto-updating?

Veerry interesting. Not a bad idea. Probably can do it.

I don't believe any of you. Why not let the user decide what works 
for him ?

Security fixes should only break insecure code. Otherwise they are 
API modifications.

Only the user knows when it's working and when not.  Well, as I said, 
I don't believe any of you to stick to that 100%. It's an admirable 
goal, obviously.

Well here's a side-by-side problem scenario. Grandpa doesn't know 
anything about anything, other than how to check his e-mail. He comes 
to web site 1 which auto-installs (with his permission) REBOL 1.3.2. 
Then he goes to web site 2, which needs REBOL 3.0, and it auto-installs 
side-by-side. Then he comes to a third site, which tells him it requires 
the REBOL/Plugin. How does he know which plugin it needs?

Actually, Java isn't a good example. Their updater sucks. Better 
example, like .NET.

Further, let's say he decides to clean out his computer. If he removes 
REBOL 1.3.2, seeing that it is an "old" version, he will inveitably 
break the web sites that rely on 1.3.2.

Yes, but he must take responsibility for his own actions there.

How can you take responsibility for an automatic updater's actions 
?

Sure, I understand that makes sense for developers, but I can see 
real confusion. Since when does a web site tell you that it requires 
Flash version 3.0? All Flash scripts run in the latest version of 
Flash, so if you have Flash 8, you're all set on any Flash web site 
(I think...someone correct me if I'm wrong).

The plugin should look at parameters to see which version is needed 
(or the Needs header) and load the latest in the applicable line. 
If it is not installed, it should offer to install it.

Remember, we have to think about Grandma Sally who just figured out 
how to use Internet Explorer. If she gets frustrated with this thing 
called "REBOL", we're outta market share. It's got to be easy for 
even her.

Rebol 3 is not going to run Rebol 2 stuff, so we're not like Flash 
straight away.

Since REBOL is so small, parallel installs make more sense than compatibility 
modes. This isn't Perl or Java you know.

My plan above is easy to implement for now. It's good for us developers 
in the near term.  Later we can add a complex auto-update scheme 
which can be manually switched on by a right-click menu.

Hmm. Interesting. I need to think about that one.

Right now, the plugin is linked to its version of viewdll. It can't 
really "choose" which viewdll to load.

Especially since, with a new release,  we may need new features in 
the plugin *itself*, and not just in viewdll.