World: r3wp

Peter - have you checked, that e.g. R2 works? I mean - that generally 
CGI is working for you? Just asking :-)

Henrik - what is your request specifically about?

Yes, I did Pekr. The same script runs using R2.5.6 under Apache on 
Windows

Henrik, have you purchased a Linode server for your stuff now?

Graham, yes, have had one for a few months.

$20/month?

Pekr, well, we have to figure out to extend the R3 console to javascript 
and basically do a console in a browser. It could be a big job.

Graham, yes.

I think Frank did a Rebol in Java which was accessible in a browser 
.. or something

I think that defeats the purpose, by using Java.

Haha, now I know where your request comes from. Carl joking around 
Ruby console :-) http://www.rebol.com/article/0427.html

Henrik, I think that Pekr is thinking of a browser alternative rather 
than a one to one replacement. 


Perhaps it would be difficult to use an extension to embed one of 
Mozilla's monkeys in R3.

Freebell .. that's what it was called.

PeterWood - I am not thinking at all - I just throw wild ideas here 
and there :-)

Some requirements:


1. It would have to be a real console, so we can't simply send CGI 
jobs and close REBOL again.
2. There would have to be a way to spawn and kill consoles.

3. REBOL 3 will have to live up to its ability to limit itself memory 
wise. CPU hogging, we can't do much about. My Linode only has 384 
MB RAM right now.

4. The Ruby console can respond to various input and display help 
text related to what you are typing. This can be used to create tutorials.

5. I have a Cheyenne on my Linode. It either has to use it or not 
collide with it, if we don't use it. Can Cheyenne use a special R3 
process?

6. Managing the console output will obviously need to be done with 
AJAX.

7. Syntax highlighting seems a little superfluous right now, so the 
target right now would be a basic console.

8. In case this is too much on my Linode, I'd like to remove the 
console again. Then perhaps it would be better at that point to invest 
in a dedicated Linode server. :-)

rebol doesn't need 384 mb to run

not as one process, but 10-20 users simultaenously? 100 users?

call "rm *"

Well, we don't want access to that. R3 will have to live up to that 
as well. Good one.

Linux can swap, no? If I would be about to judge R3 console quality 
upon Windows, then well ... don't let user to use 'call, this is 
totally messy  ....

It depends on the data.

The question is, if it should create sandbox for each user, I mean 
letting user to download something, save something, call something, 
parse it, etc. Or do you want to limit console to prevent file operations 
for e.g.?

do join "call " "init 0"

Optimally the sandbox would have to be handled entirely by R3 alone.

Henrik - the only option you have in limiting system resources is 
some CPU cycles for R3 process. Carl refused to add e.g. time/memory 
usage variation ...

Graham, I think this can be intercepted with LOAD. Perhaps you can 
redefine CALL to become harmless, or simply return a restriction 
error.

the secure feature will have to be set so that everything is secured.

this will limit access to external stuff... doesn't call have its 
own secure option?

'call has its own security setting IIRC ...

Pekr, yes, that will be an issue. But I think Carl will eventually 
comply, once he sees that this is a problem.

Max was faster :-)

I wonder if there are generic javascript ajax consoles around we 
can grab...

Henrik - sometimes you have to ask Carl more than few times in order 
for something to be noticed :-)

Pekr, once he sees my poor smoking Linode server brought down by 
R3, he'll notice. :-)

It has to be also settable by command line option, or it does not 
have any sense. Your user will not add it to his script himself ...

true

I wonder - what happens, when user types "demo" and View is supposed 
to be launched? An error?

hmm.. tried this briefly in win32:

>> call "dir"

** Access error: external process failed: "The system cannot find 
the file speci
fied.^M^/"
** Where: call
** Near: call "dir"

What's call's environment?

henrik - we discussed it here with BrianH week or two ago. CALL is 
now more low-level, hence use call "cmd.exe /c dir c:"

Pekr, I see, thanks.

dir isn't a prograam, it's a cmd.exe command.

http://tryruby.sophrinix.com/js/irb.js

Also look at my rants in #1223 - call needs some fixes, or it reqires 
you to press enter, once it finishes, as well as it messess console 
output (prompt), as well as call output can't be caught into series 
...

Pekr, demo is a mezz. Another issue is graphics commands, lowlevel 
View and such. How do we handle that? I'm not sure we want to submit 
graphics via HTTP to the browser.

Also what happens if you forcefeed R3 with events? is that possible?

Henrik - we might have more problem that that. Even with real plugin 
- imagine networking - we have our own networking, we don't use browser's 
one. For the console demo, it should not be probably a problem though 
....

that looks like the JS that loads into the console div

Actually a RT branded Chrome browser would be great .. have R3 embedded 
into it.

Pekr, we can shut down networking too with SECURE, AFAIK.