World: r3wp

If we could configure plug-in some-way, those behind proxy would 
at least normally edit their user.r and do some tweakings, not so 
with proxy ....

eh, not so with plug-in version I mean :-)

but other than that, the news is fantastic!

how did you decide to some "major version" update process? E.g. View 
1.2 to 1.3 (lot's of changes, possiblitiy of code being broken) or 
View 1.3 to R3?

Pekr: You should ask Carl about get-net-info. Maybe he can fix it 
for the next /View release. (remember, the plugin is built against 
the current /View release -- in general, we don't make major changes 
to /View with plugin builds)

ah, of course, sorry .... now I get it - plug-in dll and view dll 
are two distinct things ...

how can I reach Carl the best way? Feedback? RAMBO?

Yes, exactly. Sorry that wasn't clear before.

Maybe put a detailed bug on RAMBO and I'll mention it to him, that 
this is a problem esp. for plugin users because there's no user.r.

wonderful news, Josh. I'm really looking forward to something that 
can be demoed to users.

is it still Windows only?

Pekr: Backwards-compatibility w/REBOL, AFAIK, is only broken with 
the first digit changing (i.e. 1.x to 3.x). We'll follow that process 
with the plugin -- automatic updates from 1.2 to 1.3, 1.3 to 1.4, 
etc., but a new manual download for 3.0 (including new HTML, side-by-side 
listing in "Downloaded Program Files", etc.)

Henrik: yes. I'd be curious what the Mac or Linux demand is.

I'd think there would be some demand for a mac version. switching 
to mac everywhere here :-)

Henrik, thanks...good feedback.

Note: After some research, Pekr and I discovered that you can place 
a user.r file in the "sandbox" directory (system/options/home) with 
your proxy settings to get around the limitations of set-net-info.

That may be a temporary solution for those of you stuck behind a 
firewall.

Thanks a JoshM for the solution. Although that is not final solution 
(plug-in demos will not work for those who directly click the link 
on website), with some user assistence, doc update, we could get 
it at least working, which is really cool!

does proxy work behind squid ?

Will we get ssl for the plugin?

iirc we have squid at work, View works, so should plug-in imo ...

Ok, I know that beer doesn't

Altme doesn't

We are looking at SSL in the future.

Altme doesn't? Is that problem of altme? I doubt it - altme uses 
proxy settings ... but it uses world look-up, and for that single 
thing is requires some special port opened on firewall, thing our 
admins will not do for me ....

How about encapping product for use on plugin?:

Good to know that rT is considering releasing SSL somehow...

Graham, we are looking into that also.

(We are looking at the idea of securing source code, not necessarily 
"encapping" per-se)

Ah, good.

securing? hooo ho, so maybe finally we will be able to work with 
certificates in rebol? :-) That would be uber cool :-)

Yes, certificate support are also needed if we are going to replace 
those java banking apps, and medical applications

As a suggestion for dealing with proxy issues, why not have the plugin 
dll read the browser's proxy settings and then call the View dll 
with some REBOL code that would set its proxy settings accordingly?

that's what it does now.

it does not imo anything like that ...

plugin dll imo does not do anything, just starts View with some parameter 
.... it is View's get-net-info, which is outdated (look at the source) 
and incorrect. It looks at incorrect Registry setting

I mean, once the security infrastructure is set up properly in a 
future version of the plugin, anonymous scripts shouldn't get a persistent 
sandbox at all, so there would be no place to put a user.r.

that is why even normal View is not able to get control panel proxy 
setting

Brian's suggestion might work, but not sure Josh will do it, as he 
already suggested we should contact Carl, to fix View code involved 
...

ok, my bad understanding

no persistent sandbox? what do you mean, please? Are you suggesting, 
that our plug-in apps, should not rely on local storage? I am not 
sure I like it ...

Imagine plug-in version of IOS. Currently the sand box is in Temp 
dir, which get's purged by control panel setting. I don't want to 
lose MY local data :-)

I have gone over this before - the key word is anonymous.

maybe I don't understand what you mean ....

Josh's aforementioned secure source code was something I suggested. 
The other part of the suggestion was that every secure script would 
be cryptographically signed by an SDK license key, or some other 
way for RT to trace the author of the script. Only those signed scripts 
would be allowed to store persistent data in a sandbox without the 
attempt to do so prompting the user with a security requestor.

so in your opinion, plug-in should not be allowed to write even in 
sandbox dir?

Scripts that aren't cryptographically signed (anonymous scripts) 
would be limited in what they can do on your system.

my question was a bit different, though. Let's imagine your proposed 
secure way, so I can use it for some app, to sync some data to user. 
The problem for me is the sandbox placement - in system Temp dir, 
which can be purged via control panel. I am not sure I like it, if 
there is possibility I could loose my synced data. Or am I missing 
something?

Your last reaction to when I brought this up:

OK - one thing is clear now - "What would you let your worst enemy 
do with your computer?" should be a saying for Rebol plug-in .... 
now just how to represent it ...

My suggestion was just for anonymous scripts. Signed scripts could 
get a sandbox, probably somewhere under %appdata%.