World: r3wp

It is the intension that all of this be easier in R3.

tion

Did Carl published any example code of how such plugin code would 
look like ?

Aside from knowing that they will be based on modules, no work has 
been done or published on plugins. Since even the module API is a 
work in progress, that means that all we have is discussions (unless 
Carl has been working on it in his current coding session, not as 
unlikely as you may think).

Brian - it is not correct that no work was done. Carl told me few 
months ago, that plugins are some 80-90% done. They have forma API, 
they are just disabled. The plugin simply exports some info for REBOL 
to load and bind or something like that ...

Some info from Carl from the past:


The DLL access is very complicated code that is specific to every 
CPU and OS.The DLL access is very complicated code that is specific 
to every CPU and OS.

The problem with plugin is not the code itself, but the security 
of it.

If we can set security aside for a while, we can certainly have the 
method for it.
I think it is probably ok for 3.0 to make this statement:

If you want to use plugins, you can -- but, you will want to only 
use those from trusted sources. Do not execute unknown plugins from 
the web.

the complex part of the security model is some method of digital 
signing.

We could use a simple hash method, but the problem is with public/private 
certification.

What makes it complicated is that we must port the R2 encryption 
code to R3.
That project could take a few weeks.

security for plugin should be the same as for any fileacess no ? 
 and once again you are not supposed to use software you didn't documented 
before on it. I think there is more risk to damage you computer and 
data by simply surfing the net with IE 7  than using rebol.

DLL  are black boxies you only can figure out the I/O  inteface what 
is precisely done in the plug is impossible if you don't have access 
to the plug source to figure out

does because I can get a virus surfing the web i will stop surfing 
the web ? does because i can get virus through the maili will stop 
using email services ?

Does rebol can countains 100%  of all the technologies ? Does rebol 
will be enhanced anytime some of those manies techs are improved 
? Looking to those simple fact it's obvious  rebol needs external 
extension system.

after if you really want to bring a 100 %  plug security you have 
to make the plugins centralised done only by RT and with some asymetirc 
key control system to ensure no one have modified the DLL  betwin 
RT repository and the customer compurter

now in day to damge your computer you just need to log it to internet 
without firewall and anti-virus no even need to do anything your 
computer will be infected straight by a tons of worms

Pekr, I am glad to hear that some work has been done on plugins even 
though the module model isn't finished. We have discussed the security 
issues before in the blogs and their comments. The CPU/OS problems 
could be partly resolved by doing some CPU/OS-independent standardization 
of the REBOL side of the plugin model and let the OS side take care 
of itself. Defines in C headers and all that.

digital signing is not the problem the problemis to whom rebol will 
ask a 100 %  trustable footprint patern ?

if RTmakesavailable  a signature bank for trusted pluging and when 
rebol runs a load-plug command this function send the name of the 
plug +  actual signature and compare it to what is stored in RT's 
bank but this mean offline using of plugs will be impossible

Could simply require confirmation on first run... when you retrieve 
the plugin.  Then only check again when online.  This wouldn't prevent 
the plugin from working.

Hum I proposed long along when I was complaining about load/dll unfriendly 
shape to make a ported library repository wich you can find the standard 
libraries and the bridge to use them . the repository could be acknoleged 
by RT who will grant the lib is tested and safe download it and distribute 
is widely

now it depends of how do we considere the rebol sharings. what about 
those who want to build custom "plugins" based on official other 
libs but with only in it what htey need and not the whole thing (like 
SDK allows you to customise the VMrebol version you are going to 
share with your application...) Like rebolinforms the user when a 
rebol script is accessing external data it will be first  an information 
about the fact the script is about to load a plugin   and ask for 
user to continue or cancel. And if the user says yes then the answer 
is stored by rebol (in registry for example) so in next run the user 
is not bothered anymore. If the user is plugin to internet then rebol 
could check on the offical repository if the plug is safe or not 
this will give the user  an ensurance that the plug is safe.

once the reply from officialRT plugin repository is retreived then 
VM rebol store the answer to not have to redo the checking on each 
run

once again load/DLL  exists for a long time but we can't says that's 
a widely used feature. Most because doing a bridge .R is painfull

Just tried Windows Speech Recognition on my Vista laptop and 2.7.6 
.. and it doesn't work.  I can dictate single letters into an area 
but not words :(  Hope R3 is better in that respect.

i dindt' even known it speeche recognition would work with rebol/area 
....

waow

Apparently Dragon Dictate is able to dictate into an area.

hum I figure out it works ...

audio converts to text and send it to the curent text field as if 
it was a normal keyboard input ?

there's more to it

Windows Speech Recognition must look at the context to see if the 
region with focus is a text field.

and it's not recognizing VID fields

There's no way Windows can figure out what's in View windows. If 
WSR needs really just a native text field, a solution could be to 
make a true, but not visible, native text field (CreateWindow( ) 
API), give it the focus each time a VID field has the focus, then 
get the input data on events received from the system:// port.

Hope this isn't prophetic:

http://books.google.com/books?id=ioN368DebtcC&pg=PR5&lpg=PR5&dq=rebol&source=web&ots=oz0DV1kpiC&sig=yCHQGTC5eFW2emCdYd-xH4lqMnI&hl=en&sa=X&oi=book_result&resnum=8&ct=result

;-)

hasn't buried the competition yet.

Henrik, you mention the rebol3 browser quite a bit. Just what is 
it? Perhaps you have written about it previously.

Carl's new VID work.

He has stated that he wants REBOL's GUI to be more declarative, with 
structural and presentation cleanly seperated, and network access 
and services fully integrated. Sort of like HTML/CSS/HTTP done right: 
A REBOL browser. That is what he has been working on these last few 
months, what we have all been waiting for.

It sounds cool to me, but I have been really looking forward to the 
core changes that are coming with it :)

This is why Carl's work lately has been worth waiting for. I mean, 
if it was just a GUI framework that would be silly, right? :)

The idea of the REBOL browser is to replace the Viewtop paradigm 
with a webbrowser paradigm, because people will relate to that much 
more. You have a standard browser-like window. You enter a URL and 
get a "page" or a script run from that location displayed in the 
window. I mentioned earlier that I felt Carl was trying to restart 
webbrowsing. Carl's situation right now is probably right where Tim 
Berners-Lee was back in the early 90's as he was finishing Mosaic 
1.0. Carl will just be starting in 2008 with 2012-type web technologies, 
rather than 1994.

I fear our expectations are maybe too high. Not sure we could create 
anything revolutionary here?

starting from scratch is pretty revolutionary in itself, but I haven't 
seen the browser yet, so I can't say for sure that it will be exactly 
like I imagined.

Our expectations for what we will get out of this are probably not 
too high. Our hopes for getting this adopted by others, that may 
be another matter. It's one thing to build it, another to get people 
to use it.

if it will be like I imagined, it's going to be one heck of a tech 
demo.

But we can already do one: Just 'do a complex VID script in the R2 
console, such as Devbase and see how fast it loads. Now do the same 
thing in AJAX.

Not that wide adoption and vindication wouldn't be nice... :)

I think for wide adoption the browser window needs to fit inside 
an ordinary browser window as well. If it works somewhat the same 
way as the native rebol browser (lacking certain rebol browser features), 
you have a pretty good demo of what it would be.

for wide adoption the browser window
 => "for wide adoption the REBOL browser window"

needs to fit -> needs to be able to fit when necessary

Take that with a grain of salt though - I use REBOL for server-side 
stuff most of the time.