World: r3wp

making classes, functions, and data private and untouchable for security 
and code stability reasons are things which would allow REBOL to 
PITL.

Volker - then any new concept addition will ruin rebol for you, as 
you will have to learn it ... View is gonna be overhauled too - changes 
to face and who knows what .... from recent blogs, I can only see 
positives in getting them. I have a trust in Carl and that he is 
going to do those things in sensitive way ...

sorry to argue Volker but parse is not easy to grasp.

I can use /core without knowing about view at all.

Volker and Pekr, you are on the same side  ;-)

parse is not easy to grasp. but its not the only way to define dialects.

nope.

iirc modules will not intercept basic code and aproach to code? You 
don't have to use them at all?

As dialect-grammars can be parsed by parse and urned into parse-rules.

modules they are simply protected contexts with rules on sharing 
data to-from the modules.

I have implemented many dialects which are 100 miles from parse.

Glass was an example of a programmable dialect.

(the old glass, from 5 years ago)

is there any new glass? :-) (as you talk about old one ...)

I'm not saying parse cant do anything... its just something some 
people "get"  and some others dont.  I am of the latter kind.

yep. the one which is being worked on right now.

hence the !GLASS group. :-)

I am not against modules. I am against thinking "put things in namespaces 
and you can hide and forget them and they still work smothly together". 
That works when i am ready to hide a lot more than i would write 
otherwise. (that "only 25mb!!"-thing)

as with anything Volker, tools dont guarantee success.  useage of 
them does.  imagine rebol without contexts?

modules just extend them and allow us to make SURE they don't affect 
other code and dont get affected either.

I just don't want REBOL itself and all its mezz code or view to become 
private.

which is where Volker, Pekr and I agree I think  :-)

If they are used like this, i agree. But its easy to build modules 
which depend on modules. And i often hear "lets build great libraries 
for everything". If they are really used to keep stuff out of the 
way, without adding dependencies, i think on us we agreeing :)

(hum, my grammar..)

hehe

I guess the question is does library code isolation *need*  a language 
extension like modules or namespaces?

Or are existing contexts good enough provided we take care to avoid 
creating global words?

but protection is be required.

I opt for auto-protection for global words. So i think modules are 
a good think.

I wish the damn protect word had an option to make unprotecte impossible.

how can I garantee loaded code is safe?  ITS IMPOSSIBLE once you 
say OK to file I/O

unprotect: :none
:-)

something to add to R3... proper sandboxing of I/O.

good trick for some cases, but then you can't legitimately unprotect 
stuff while debugging...

Thats the other thing. IMHO modules go not far enough. For frameworks 
i want complete sandboxing of user-code, including quotas. Modules 
go not far enough. For libraries i am worried modules make large 
amounts of code to easy to write (only a little bit worried, or maybe 
just paranoia?).

The issues you are touching on  are all easily circumvented.

If I have your *source* I can easily preprocess it before DOing or 
LOADing it to make whatever behaviour changes I like.

That makes it impossible in a source-level library to get total protection.
Binary modules, that's another issue.
Paranoia is good!

Currently i thnik about including a web-server and use cgis which 
call cgis. then i have no need open things up later, just close them 
enough, do job, exit.

but sunanda, are you going to verify code like glayout (150kb of 
ugly code) for each subrelease ?  not talking about bad intent.. 
just possible dangerous bugs.

Sunanda, its about the protection of the loader, not the loaded IMHO. 
The loader should be able to protect the exe before doing untrusted 
code, and unprotect it later ("shoudl" as in "thats a wish.")

Yep, that bugs are a problem, not only intent. If i have a daemon 
24/7, add a feature which bugs 2 hours later, when i am away, and 
i am bag tomorrow, with the daemon down, thats uncool.

and with harmfull intent... REBOL being what it is, its very easy 
to hide nasty stuff inside obscure code, building up words on the 
fly and setting them from the value of another word ... bla bla.. 
all that stuff is almost impossible to catch with scripts and if 
its nested within similar code, you'll just breeze through it when 
scanning the whole.

cgi-servers can handle this to some extend, but cgi is cgi and not 
chat-speed.

Volker. That's true (and I've said it myself too: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMGVC
)
But we need to protect "my" library against your loader too.
That's a separate problem.

can you imagine that not being able to know the current login name 
is case enough for REBOL not being used in multiuser office environments. 
 that is something which MUST be addressed in R3 its a simple call 
to the socket lib (IIRC) and if protected, then that info can force 
apps into being multi-user oriented.

I am not sure i like DRM. But i agree on the "separate problem".

right now, its all kludge, hell even the install dirs and setups 
are not consistent between my two machines installed the very same 
way  :-(

WIndows does not store the name in a user-var?

environment vars are not secure in any way or fashion.

But the machine running your scripts can be trusted?

Script to implement a sandbox:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlDGDS
No idea if it works ot how easy it is to cirumvent.
But maybe it could be used to prototype modules.

The machine is trusted, but can you trust the user running it?