World: r3wp

For example let's say there is rebol interpreter that holds some 
big data in memory and listens on some port. You send it a function 
that if will run on data items to determine if you want that item 
or not and send you the filtered items. If you could know that the 
function used for filter is pure e.g. only returns true false on 
some given item, and can't touch anything outside would be very nice 
even if you trust the source of filter function, and critical in 
cases where you cant.

(and in most cases you can't really trust anything you get over network)

Typically such systems don't send functions around because they can't 
be trusted

So, Beer, Rugby and LNS don't do that....

yes, but sending a function / code over is probably the most effective 
way to execute on the server side and also the most consistent, not 
that you have to invent some subdialect that you then interpret. 
If you knew function is pure or locked/prevented to touch anything 
outside it you could trust it.


And using code as data directly not reinventing some limited "code" 
for stuff like this is the whole strongpoint of rebol and lisps. 
That's why they say "Any sufficiently complicated C or Fortran program 
contains an ad hoc, informally-specified, bug-ridden, slow implementation 
of half of Common Lisp."


for example you have a database of users, you want to get all who 
are between age 20 and 30 ... you can send it  function [ user ] 
[ all [ gerater? user/age  20 lesser? user/age 30 ] ]


If you can't do this how else could you solve it so elegantly? And 
you would have to use/learn as client (and code on the server side) 
some limited and "a little different" language to do it

basically even better for this specifically would be that you could 
run a function in some sort of locked sandbox provided by runtime.

If you run your own systems you can be as insecure as you like.

But most people would send the request as a dialect and let the other 
side do the query.

so, if you can cryptographically sign your function ... and then 
send it ... well.

if each internal system is secure on it's own owerall security is 
better. for example if you controll the client in this story too 
you think you all is well, but you could still crash the server by 
mistake, for example owerwriting some global variable of it, and 
input data that you get from users (in case of an webapp) can then 
include various techniques for code injections (like they do now 
with SQL injections)

cryptograpically sending it wouldn't help in two examples I gave

because in both the main point is that you can't trust yourself 100%

if you can't trust .. don't do it.

what if runtime provided sandboxing. I know I know much too little 
about rebol but I imagine with all the good stuff  it does something 
like this would not be theoretically impossible ?

A sandbox is a long-time wish of mine:
   http://www.rebol.org/ml-display-thread.r?m=rmlNVBC

REBOL3's security policies start to make it possible:
   http://www.rebol.com/r3/docs/functions/secure.html

you would have to protect all your globals!

yay! now it's a wish of two :)

Let's move this to another group ...

ok which one?

You choose ...

I can hardly ever find what to post where here :=)

Try core ...

Anyway to clear the screen in the console short of starting a new 
session?

you might try with con: open console://, but dunno how to proceed. 
Nor insert nor write works on that port ...

>> probe system/schemes/console
make object! [
    name: 'console
    title: "Console Access"
    spec: none
    info: none
    actor: make native! [[end!]]
    awake: none
]

doesn't seem to do much ...

slightly less functional than the dns scheme

== make object! [
    name: 'dns
    title: "DNS Lookup"
    spec: make object! [
        title: none
        scheme: none
        ref: none
        path: none
        host: none
        port-id: 80
    ]
    info: none
    actor: make native! [[end!]]
    awake: make function! [[event][print event/type true]]
]

:-)

unbelievably .... how much functionality we miss even compared to 
R2. And we dare to call it  "soon"-to-be-beta product

It does have more functionality than rebol1 beta ...

and more than 0.9x alpha ... I still have one somewhere :-)

We have to wait a bit for Carl to come-up from his cave ... hopefully 
he is cooking something here or there :-)

see .. it could be worse

looks like his still doing site maintenance http://twitter.com/rebol3

oh well... time to play with the host kit.  Downloading visual studio 
8 ...

Just to be picky: you can't actually infer from `actor: make native! 
[[end!]]` how much a scheme does

rebol3 is not in a process of production but design + production 
so I would not be too restrictive on carl jumping from one thing 
to another. he is also only one, so he can't just do r3 for 2 years 
straight

Implemented the http://www.rebol.net/r3blogs/0300.htmlmodule EXPORT 
keyword. See http://curecode.org/rebol3/ticket.rsp?id=1446

Next up is http://www.rebol.net/r3blogs/0274.htmlcompressed modules/scripts. 
I have some interesting tricks to make them seamless to use and make, 
but I have to get a little sleep before I can really dig in to them.

Do we need SHA256 in checksum ?

Not a bad idea - what uses it?

Amazon

Interesting, how do they use it?

for signing requests

Sounds good. Request it in CureCode.

Eg. Here I use SHA1 http://rebol.wik.is/S3

but I guess they might want to only allow SHA256 in the future

SHA1 has been having problems lately, iirc (which I likely don't).

Do we have an url-encode function?

This doesn't look good ... http://www.curecode.org/rebol3/index.rsp


new issues are being created, but there's a sharp decline in closed 
issues

We were focusing on other things for a while. We're bug fixing now 
though.