r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Pekr
10-Sep-2009
[17384]
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 
....
Graham
10-Sep-2009
[17385x2]
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.
Henrik
10-Sep-2009
[17387]
Pekr, we can shut down networking too with SECURE, AFAIK.
Pekr
10-Sep-2009
[17388x3]
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 :-)
Henrik
10-Sep-2009
[17391x2]
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.
Pekr
10-Sep-2009
[17393]
could spammer wrap the process to its advantage?
Henrik
10-Sep-2009
[17394x2]
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.
BrianH
10-Sep-2009
[17396]
You can prevent READ anything with SECURE.
Henrik
10-Sep-2009
[17397]
Can we prevent the creation of ports in case someone provides a low 
level alternative to READ?
BrianH
10-Sep-2009
[17398]
Yeah, all file operations, even through ports.
Maxim
10-Sep-2009
[17399]
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  :-)
Graham
10-Sep-2009
[17400]
Pekr, it would be Chrome + Rebol ...
Henrik
10-Sep-2009
[17401]
Maxim, hmm, yes, but does this not require tasking?
Graham
10-Sep-2009
[17402x2]
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.
Maxim
10-Sep-2009
[17404x2]
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
Henrik
10-Sep-2009
[17406]
Graham, perhaps we should simply log everything typed into the console. 
This would be nice for debugging purposes as well.
Maxim
10-Sep-2009
[17407]
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?
Henrik
10-Sep-2009
[17408]
http://97.107.135.89/projects/rebol/r3shell/


The humble beginnings. Nothing working at all yet. Just some boxes 
and HTML.
Maxim
10-Sep-2009
[17409]
I like the warning  ;-)
Henrik
10-Sep-2009
[17410]
:-) I suppose we want a standard 80 column console.
Pekr
10-Sep-2009
[17411x3]
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 
...
Henrik
10-Sep-2009
[17414x2]
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.
Maxim
10-Sep-2009
[17416x2]
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).
Pekr
10-Sep-2009
[17418x3]
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 :-)
Henrik
10-Sep-2009
[17421x2]
line wrapping now available too
http://97.107.135.89/projects/rebol/r3shell/


A tiny bit of progress. No visible cursor yet. Limited console history. 
Only capitalized chars (dunno why yet).
Pekr
10-Sep-2009
[17423]
It does not display anything here, at least not in FF nor IE. Do 
you have any real output from R3 console already? ...
Henrik
10-Sep-2009
[17424x4]
IE does not work (surprise)
just had an error in my code, try reloading, I won't edit for a few 
minutes.
there is no R3 yet, only trying to get a decent console for now. 
returned values are just echoes of the buffer.
Actually, the R3 part can be handled by someone else, if you feel 
free to try. we should just agree on how to talk to eachother. I 
can submit an ajax request and then output whatever is returned in 
the console.
Steeve
10-Sep-2009
[17428x3]
Damn it, how can we throw an handmade event! ?
when i construct an event! with something like:
>> make even! [type: 'minimize gob: my-gob port: port-event]

i got:
** Script error: cannot set gob: field to gob! datatype

Wtf, i can't set the gob field with a gob ??????
Each time i try to rework on new gob styles, i'm stoped by such lazy 
bugs
Henrik
10-Sep-2009
[17431]
seems that capturing the correct keycode is a bit chaotic in different 
webbrowsers.
Pekr
10-Sep-2009
[17432]
Steeve - put it into CureCode ... maybe we ignored GUI related bugs 
for much too long ...
Henrik
10-Sep-2009
[17433]
Ever so slight improvements: got some more decent lower case chars 
now and cursor movement seems to work OK. IE still doesn't work and 
many special chars still don't work.