World: r3wp

(moving to Printing group)

Does R3 already have support for loading DLL ?

I don't think so, as the library API is considered to be a good candidate 
for a complete redo as the Plugin API.

That doesn't mean we can't get started on designing a good printing 
dialect.

Having the plugin API is good for static linking, but dynamic linking 
will still be needed (unless I missed something about R3 plugins?).

You did. R3 plugins are to be a cross between a REBOL module and 
a library wrapper, and can be dynamically loaded like modules.

So, do you mean that with R3 to access a DLL I have to build (in 
REBOL and/or C) a plugin, then dynamically load the plugin and then 
the plugin will load the DLL ?

It's not that different from writing a script wrapper for a DLL now, 
just easier and more powerful (in theory).

Does the DLL wrapper need to be written in C or REBOL ?

I gather that it depends on how awful the DLL's API is. Again, in 
theory because we haven't done plugins yet.

I expect that most useful wrappers will be a mix of both.

Well, in R2, you always have the option of writting a small wrapper 
DLL in C to interface with a complex API, if it's not possible to 
make a direct wrapper with only REBOL code.

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