AltME groups: search

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

I like the API being able to wrap a one dll from each generation, 
and then update that dll for security fixes.

Our original thinking with the plugin was as follows: Web site is 
responsible for everything. If web site requires new version of plugin, 
it specifies a new CLSID and forces the user to download it. The 
problem is, then you have 5 "REBOL/Plugin" objects in Downloaded 
Program FIles. Thoughts on that approach?

It's a simple "proto-form", good for development while we think and 
argue about a good update mechanism.

I also like being able to specify the REBOL generation in the Needs 
header of the script. It is more reliable than requiring it in applet 
params, and more compatible with View. Still, aplet params may be 
prefered if you don't want the launcher to have to read REBOL headers.

And my kids are more savvy than Grandpa Sally

And we have to be cross-platform back to 98

Rarely. They're quite common for user tracking, AJAX receivers and 
exploit code.

Running a REBOL/Services client in a webbug and having it control 
the browser through the DOM could be useful though.

So, we have a few different scenarios (using the numbering from above):

 1. In this case, the activex system in IE will force the download 
 of the (digitally signed) CAB found in the htm, which will come from 
 RT, and contain the Plugin version that works with this system. Nothing 
 new is required, this is how it works now.

 2. Here we need to enhance REBOL somehow to check for a security 
 update, prompt the user, and download an updater EXE. This is where 
 I think I will work next.

We could be conservative and not make unrequested non-security updates.

Does Firefox check for updates to its plugins? I thought it just 
checked for updates to its themes and extensions but let the plugins 
update themselves. It does seem to provide a plugin registry though.

Assuming the plugin will become wildly successful, maybe there should 
be a way to have the initial plugin download and subsequent updates 
come from a site other than rebol.com so that any outage there wouldn't 
affect users hitting a page calling for the plugin. I wonder how 
high load is handled for the Flash plugin?

Does the current plugin have the ability to "pop-out" the browser 
window and create a self-standing application window like a Java 
applet?

the first window you create is inside the browser, and the ones after 
that are outside.

@Graham - So it's not quite like applets where the applet can jump 
out of and back into the page?

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?

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

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.

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

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.

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.

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?

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.

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

Or, is this a chicken and egg situation?

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

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

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

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.

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.

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 :-)

Q: 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 -

A: That is a choice of the developers.  The fact that people leave 
it as "default"


Q: 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 :-)


A: "I" over estimate Flash?  Uh, er….you mean like how Yahoo over 
estimated Flickr (front end is Flash), and bought them?  


Or, while you might not like it, if you are looking at an animated 
ad on the web, there is a good chance it is Flash.  That would be 
a 500 billion dollar industry that is using Flash as their delivery 
mechanism.  That is the app, animated content with games and click 
through.


And if you use T-Mobile, then you are using Flash.  Yup, it "is" 
the interface for their cellphone content provider.



Pekr, I'm not a fan of Flash, or Macromedia…I'm simply stating that 
Rebol should consider Flash's model as a pathway to a clean install 
and plug-in interface.

A smart plan is simply take the plug-in that is the most pervasive 
(I'm voting Flash for this) and copy their interface.  That simple.

reichart, it's possible that pekr means that you overestimate flash 
for use in applications, but I agree, we should definitely look at 
what Flash did and copy that where applicable.

And flash works in Apple widgets.

With Java, the applet is only allowed to communicate with the server 
that served up the applet. We could make that same restriction by 
default in the REBOL plugin with SECURE, and then relax the restrictions 
at runtime with SECURE again. Of course, that will cause the security 
requester to pop up and the user would then know what they should 
know and agree to anyways before such behavior is allowed at all.

Reichart - it is exactly as Henrik said - I just meant "real life 
apps", while you mentioned mostly media stuff, which is imo not Rebol's 
target and imo never will be, unless we would get some rebol authoring 
IDE, which I don't see coming in a year or two ahead ....

as for browser preference, for me it is IE, FF, Opera, other ...., 
I can see Opera dominating embedded space (PDAs, cell-phones), but 
maybe it is because penetration of OS-X here is nearly non-existant 
... but as someone pointed out - whole world except MS uses Netscape 
API plug-in and even for IE, you can develop ActiveX, which wraps 
the same plug-in, so maybe RT would not have to develop separate 
versions .... otoh we are talking wrappers only anyway, the main 
part is View in .dll form ...

Whilst Mac is gaining in popularity with developers and may be re-gaining 
ground in the consumer market, it is still nowhere in the corporate 
world where it's still wall-to-wall windows.

..and "locked down" windows at that .... no user installs ... they'd 
 even disable browser plugins if they could

In other words, while they are about 2.5% world wide (4-7% in US), 
of personal system choice, they represent between 7% and 15% of individual 
software sales.

Wow!

I would not want to turn that market down. 

And……………my friends…………….the web is the great equalizer…

Just a quick interjection, but I agree on the installation/interface 
being exactly the same as Flash.   The flash installation is mindless 
(see http://kealist.blogspot.com/) and the plugin should be identical 
to this.   I would have done the same for FF, but I can't get it 
to uninstall.

I would make it also some 5% transparent, black and white design 
.... top bar displaying some basic buttons, date/time and progress 
dialog ... kind of minimalistic aproach ....

... and I dare to repeat the idea for rebol 3.0 - we need rebol native 
windowing, or imo we are in trouble ...

Hi all -- Carl and I are still talking about these versioning issues. 
So we'll have an update on that soon.

REBOL can only function with its own Win32 HWND window that it controls 
completely (due to message loop issues), so, in order to change as 
little as possible within REBOL, we created an invisible proxy window 
that REBOL controls. When events come into the plugin window, they 
are asynchronously posted to the invisible proxy window, and only 
then make their way into REBOL.

So the delay you're seeing is the delay between the event coming 
into the plugin and being received by REBOL, due to the post-message 
delay (it's actually crossing from one thread to another, hence why 
we are using async).

Josh - have you found out how to do 'do-browser in FF and Opera? 
Today I thought about how to properly "import" proxy settings (use 
what browser uses) - simply to use some JS facility of browser, if 
there is any such function ....

the trouble in our company is (not sure how common it is), that we 
use proxy configuration script, which gets executed by browser, and 
returns according proxy to go thru ....

do-browser in Mozilla: haven't looked at it yet. it would require 
access to both the Javascript interpreter as well as an "evaluate" 
(or execScript) method that would parse and interpret the script.

Pekr: actually, I'm sure there is, that's why you are asking. Can 
you explain the problem in a little more detail? You need that auto-config 
script interpreted? Maybe it would be easier to configure REBOL to 
rad the auto-configure script than to try to get IE to parse it and 
get the details via an API. Thoughts?

Brian - yeah, I do remember something like patents involved, but 
mainly imo it was MS move with IE 5.5, to move out from NS kind of 
plug-ins - the rest of the world is still using NS plugin architecture, 
that is why Mozilla plug-in works with Netscape, Opera and possibly 
others.

ScotT - interesting - I posted some link and said it earlier, that 
RT could concentrate upon NS plug-in only .... as there is (somewhere 
:-) wrapper ActiveX, which can wrap to NS plug-ins ....

JoshM - yes, I need the script to be interpreted by browser imo .... 
I will post you a source-code privately, as there are live IPs and 
I am lazy to change :-)

JoshM: please go to plugin-1 group, scroll up a bit to find my bold 
messages, and read on a bit, there are some findings. To post some 
notes - probably the most significant link is - 

http://www.mozilla.org/projects/plugins/


The plugin extension adobe, mozilla, apple, opera, macromedia and 
sun agreed upon is npruntime

How to host NS plug-ins in IE:

http://www.mozilla.org/projects/plugins/plugin-host-control.html

does not npruntime extension allow for both the ability to call into 
plug-in (being scriptable from the browser pov - probably java-script) 
and to access browser objects? Would be probably nice if rebol plug-in 
would support such new calls too ....

.... I sent privately my findings regards get-net-info being outdated 
and how control panel/internet settings/proxy influences registry 
keys ....

Networking: as far as the browser can do the same, i would use browsers 
io. Or is it that much slower than rebols handler? Advantages are: 
proxy, cache. Maybe there are some extensions people like, about 
adds or blacklist or whatever? if such things exists they would be 
shared too. Its security , and a computer which knows my "no"s looks 
smarter.

Proxy settings: I think the simplest thing to do here is to modify 
whatever REBOL code is detecting the proxy settings to import the 
automatic proxy configuration script. REBOL is far more suited to 
parsing text files and interpreting information than C code. As a 
side note, we're not importing any settings via the plugin itself, 
we're just letting REBOL do whatever it does normally.

Browser networking: I could be completely out of my mind, but I'm 
pretty sure that the browser sets up and tears down connections with 
each HTTP request. In other words, there's no "open connection" that 
we can just tap into -- the browser is initiating new requests for 
each page. To move to an architecture like that for plugin networking 
calls doesn't make much sense to me.......maybe I'm mis-understanding....

Josh, thanks for explanation about the delayed events. What a pity 
you cannot improve this also in Rebol2.x version as this problem 
sheds bad light upon Rebol/View apps (which uses drag'n'drop and 
simmilar features).

Well....the problem is that the plugin has to handle its own window 
events because of the COM architecture. And REBOL has to handle its 
own events for other reasons. Soo.....maybe instead of an invisible 
proxy window, we can make REBOL's window a real window that sits 
on top of the plugin window, then it would get its events directly.

Yep, understood. That's probably why the current plugin also cannot 
detect 'activate and 'deactivate events when you are focusing/unfousing 
the browser window. Do you think this could be also improved? It 
is useful for application to know when user switched to other window 
than the one with running plugin so it could manage the /View GUI 
appropriately (focusing/unfocusing fields, areas etc.)

For information about the plugin, and to install or upgrade to the 
1.3.2 plugin, please go to the following URL: http://www.rebol.com/web-plugin.html

We would love your feedback on both the IE and Mozilla releases. 
Please post specific feature requests and bugs in the corresponding 
checklists here on the Plugin world. And feel free to discuss everything 
here :)

ANd when i am awake again, i check out these plugins .)

wrt own window on top to do the window messages, etc -- I'm all for 
slamming itself on top of the browser, and not going through it to 
embed view.   or make it a "windowed" control, which is how IE does 
SELECT elements.  The complexity there is having it crop to be part 
of the page.  I think wndows media control is like that, where you 
can pick a windowed version, which performs better (probably from 
similar things that you are running into.  MSAgent runs in the browser, 
and is allowed ro roam anywhere on the screen in an irregularly shaped 
winoow.  It also starts a server process which handles all calls 
to the interactions with applications like IE and Office that take 
advantage of that aspect.  It's all asynchronous/multithreaded, and 
shuts down automatically when there are no more client controls to 
serve.


The DOM provides screen position information, but the downside is 
that with embedded controls like Adobe SVG viewer and Flash is that 
they will respond correctly to transparency (showing html page background 
through transparent parts of control  -- never got REBOL plugin to 
do that, which has something to do with wmode="transparent"  or something 
similar

and under my WindowsXP, the plug-in is obtrusive - while it is installed,I 
get IE message each time, asking me if I want to allow activeX control 
- it happens on main plug-in demo page

And definitely - interactin part - we need that config access plus 
progress bar - without progress bar, it has strange feeling, as you 
can't know, if something is happening or not, which leads you to 
reloading the page ...

guys, maybe you coudl fix older demos for new plug-in? There is link 
at the bottom of the page to user demos - bounce demo (Cyphre), and 
Color Lab (Oldes) do not work anymore ... and then there seems to 
be some spame garbage(?), which should be probably removed, if not 
functioning - it will not shed good light on us ...

Extracting the download into the plugins folder creates a sub-folder 
called rebol-moza1 containing the files.

Tried copying the files out of there back inot the plugins folder 
and  closing & opening firefox, but still no joy :-(

to know if plug-in works, the version should appear in the plug-in 
app container .... if you are not behind the proxy, script will download 
and app launched ....

Even after moving the files, deleting the folder and re-startig firefox 
I get the text "Click here to downlaod plugin" text in the container.

and you are sure that you haven't got multiple installations of Mozilla 
and accidentally plopped it into the wrong one?

If there was a way to make the plugin load up an out-of-process EXE 
rather than an in-process DLL, and if we could load up a new REBOL 
EXE for each new instance of the plugin.....we might be able to solve 
a whole lot of problems at once......for example, multiple instances....

Henrik: I can't go into specifics of the REBOL DLL, but essentially, 
its a threading issue. Each new instance of the plugin DLL loads 
in a seperate thread, and REBOL is not multi-threaded yet. Carl may 
be able to provide more specifics as to the limitations within REBOL.

I have  problems with the plugin.


After visiting the test page, if I go to other sites and later load 
the test page again,...the plugin does not load

So, with a DLL architecture, you have to load only one instance of 
the REBOL DLL, and then modify the DLL to support multi-threading. 
But with a multiple EXE architecture, it is essentially like REBOL 
is now.....one EXE per instance.

PhilB: make sure you've got it in the right plugins directory. if 
you go to about:plugins, it should appear in the list. make sure 
you coped both the DLL and XPT.

For those still unaware: New users of the plugin should visit the 
two checklists for Plugin 1.3.2 bugs and the checklist for Plugin 
1.3.3 ideas. Feel free to add new bugs/ideas.

Louis: The plug-in extracts to the "Downloaded Program Files" directory 
in Windows. This is usually at C:\WINDOWS\Downloaded Program Files. 
To uninstall the plug-in, go to that directory, right-click on "REBOL/Plugin 
Object" and click "Remove".

Dunno if my last post last night made it.  as soon as I sent it, 
the world went down and i was unable to reconnect.  I think there 
is a misunderstanding about what a windowed control is, and that 
is throwing people off.  In the post I mentioned how MSAgent works, 
where you have a central server app that communicates with all the 
instances of the control, and I think something like that would be 
perfect for REBOL.  If there was a way to create an instance dynamically 
( using new ActiveXObject, for instance), then for those plugin scripts 
not needing the View UI, that would be a nice option, because that 
would allow using it from a WSF, as well.  On a side note, when trying 
to use the plugin in an HTA it's crash city.

no problem.  I'm no good at REBOL, but I probably know IE a little 
TOO well.  I was able to create the OBJECT tag dynamically with no 
ill effects, though.  One thing I couldn't get working is transparency, 
though.  Don't strain yourself.  I'm sure it's a mess to get anything 
working.  I'll be in and out but reading religiously.

Got the Plugin working with Firefox ... thanks for the help ... will 
try and code a couple of demos tommorow.

I tried setting the plugin up on opera, but it crashed, and now i 
can't seem to get it to load any more. does anyone have any idea 
how to tell opera to try to load the plugin again? (it is listed 
as registered in about:plugins)

That is REBOL code, and I pretty much only handle the C code. Sorry 
:(....maybe you want to ask Carl or whoever is leading the REBOL 
product development in that area?

Gabriele - who is in charge of get-net-info? That function is outdated 
and plain wrong imo, not serving its purpose well ... could we somehow 
cooperate to redesign it?