World: r3wp

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.

Graham - what would be the purpose? It would be standalone app (R3 
+ Browser), and your apps would not run anywhere else, no?

Henrik - if you shut down networking, you prevent many cute examples 
and one-liners, as print read http://www.rebol.com

I think that maybe networking is not a problem. I would shut 'call 
though, or some users will try to inspect your system :-)

yes, but how do you then prevent: read http://somewhere.com/16GBiso.iso
?

Linode have some network abuse policies. I think we don't want networking 
at all here. Imagine a spammer taking advantage of this.

could spammer wrap the process to its advantage?

you could probably paste a binary that is decompressed and voila: 
SMTP server.

9. The user needs to be able to control the console. If something 
goes awry, he has to be able to type "reset" to reset the console. 
I'm thinking maybe it's possible to control several R3 processes 
through one R3 mother process or arbiter.

You can prevent READ anything with SECURE.

Can we prevent the creation of ports in case someone provides a low 
level alternative to READ?

Yeah, all file operations, even through ports.

henrik, maybe you can create modules for each session and use do 
within each module... they will be shielded from each other, but 
you'll only need a single rebol process to run all users  :-)

Pekr, it would be Chrome + Rebol ...

Maxim, hmm, yes, but does this not require tasking?

Henrik, there was a guy on EC2 who had his instance exploited thru 
some vulnerability and it started spamming for  a while. And the 
spamcop or something blocked his smtp server :(

the trouble with these vigilante groups is that you're guilty until 
proven innocent.

no whatever calls your R3 decides which module to interact with and 
just calls something inside the module which returns the result of 
a 'DO executed from within the module.

What I am thinking is that your R3 would be talking to cheyenne via 
a tcp port and the communication would include a session number, 
which is mapped within your R3 server to a specific module.  you 
could easily kill modules when some events happen like sessions being 
 inactive too long

Graham, perhaps we should simply log everything typed into the console. 
This would be nice for debugging purposes as well.

so basically, you build a little module in cheyenne which does a 
tcp exchange to your R3 server.  

the R3 server maps the request to a module, returns the molded result.

cheyenne then returns the value in an xml block which your ajax app 
did the request for.


allowing multiple handlers on the cheyenne side (and an equal amount 
of R3 servers) would allow you to support multiple concurrent users, 
but you'd have to map which R3 service is being used within the cheyenne 
module, in order to send your tcp request to a free R3 service.

does any of this make sense?

http://97.107.135.89/projects/rebol/r3shell/


The humble beginnings. Nothing working at all yet. Just some boxes 
and HTML.

I like the warning  ;-)

:-) I suppose we want a standard 80 column console.

Could Cyphre's vconsole help? He did complete console simulation 
(except multiline capability) in VID ...

Max - your plan re modules - is the isolation perfect? I mean - can't 
module set something globally, which could then influence other such 
consoles running?

Hmm, just reading that during IBC (International Broadcasting Conference) 
MS is going to show Silverlight 4 demo, along with media server 3.0 
..... man, they are fast - in 3 years they catched up Flash completly 
...

if you bring up a javascript console, writeConsole("string") will 
output a string to the console.

so we need some cursor movement and proper scrolling.

MS just integrated code they already had... its just a run time which 
basically integrates .net and directX code...

sort of like a mini embeded windows kernel... very similar in spirit 
to REBOL actually... but taking the abysmal route in terms the coding 
interface (XML aaargh ... depressing).

Yes ... but we might please some ppl in future, by doing VID-2-*, 
where *=Silverlight, Flash, JS ... the question is, how capable would 
it be, without complete REBOL-in-* implementation (which would be 
slow)

where's BTiffin? Henrik - Go, Go, Go! :-)

if we don't close networking, we might allow ppl to use R3 chat :-)

line wrapping now available too