World: r3wp

Can I have protected module members? I mean - non accessible by path 
notation?

PROTECT/hide, or inner contexts.

Modules are for code organization, not information hiding. You generally 
protect stuff using PROTECT - it works better that way.

hmm, protect/hide - where do I call it from? At what stage? What 
about having header options - exports, imports, protects? :-)

Well, I probably think about them way too much as about objects. 
OTOH - I might have some module, but I want to hide my internals 
... kind of DLL aproach - you only provide docs with the accessible 
API and the rest should be hidden and even maybe signed ...

PROTECT/hide is called in your code, generally in the code block 
of the module. It blocks binding. Once all of the code that you want 
to have access to the word has already bound to it, PROTECT/hide 
will prevent any future code from binding to it. You can't do traditional 
OOL protection because of the direct binding of REBOL, but PROTECT 
works pretty well (aside from stuff still in CureCode).

In general, R3 assumes that the developer who is creating the script 
is not an idiot, and knows what they want to do. If they want to 
lock things down then there are ways to enable that safely. Otherwise, 
it's as open as you want it to be. PITL doesn''t require that the 
system hide everything, just thaat it be possible to organize large 
systems. Protect what you need to.

OK, so what is the possibility for developer to provide users with 
some secure = signed module, with protected internals and only providing 
users with exported API? Do I have to use extensions for that, and 
mangle my code somehow? Calling proted/hide in user app does not 
help module author, if he/she does not wish to release his code. 
My questions are theoretical - I will probably never write any such 
stuff, but I would like to imagine, how some business entinty could 
aproach this ...

Signing a module only gives a user someone to blame if things go 
wrong - it isn't real protection. But I agree, code signing would 
be nice, especially for extensions since you can't just read the 
code very easily. The checksum support works for verifying the code 
matches what you expect though.


The module system is designed with security in mind, not closing 
the source. If you want closed source make an extension, or encrypt 
your REBOL source (like R2 encapping), or build your own host program 
(the R3 version of encapping), or download the source from a secure 
server and protect the words that refer to it so you can't get at 
it through reflection at runtime. REBOL still isn't compiled, sorry.

would creating a module within an extension's mezz code section effectively 
count as a closed module? is it even possible?

(sorry for not joining discussion earlier... I've been offline for 
almost a week due to my DSL modem going bust)

An extension's mezz code is itself a module, and its source is as 
closed as you can make any source that is embedded in native code.

so since we export some words and extension mezz are essentially 
unnamed modules... their content really is hidden and can't be extracted 
  :-)

although I guess scanning the extension with a hex editor will reveal 
the code inside!?

Just read a R3 blog post about the future of the alias cmd in R3. 
Someone commented that we should see the state of the art : http://www.extjs.com/products/gxt/
 not too foolish but can we do something similar with R2 or R3 ? 
That's where I would like  to go with R2 and R3 ...

The extension mezz are not just unnamed modules, they are real modules 
that follow the same rules as regular modules, including naming and 
isolation. IMPORT doesn't know the difference between a module and 
an extension.

You are right about a hex editor seeing the REBOL source though, 
unless you do something weird to generate the source instead of referencing 
a literal string. However, remember that the code in memory is the 
result of executing the code in the module source, generating the 
in-memory data. That generation can be really elaborate if you like.

last two - three weeks are really slow in regards to R3 development 
... unless Carl is doing something in the background ...

Gerard - I think that in regards to View, we might see some interesting 
things. VID3 is going to be much more flexible, than VID2. It should 
(and hopefully will) provoke skin and widget authors to come-up with 
some more professional looks. We can try to mimick ExtJS for e.g. 
Another possibility is VID3 "compiler", so that your VID3 source 
gets "compiled" to ExtJS or some other widgets, running in your browser 
.... it is very preliminary to say, where the future leads us ...

Seems links to demos on that page are dead.

September plan posted - http://www.rebol.com/article/0426.html

hmm, actually does not sound like a plan ...

yeah, what about the sound port ?? ;-)

look at detailed beta plan - it is just list of things to do. It 
seems Carl is not sure about adding sound device (for the beta)

i wasn't serious...

But rebolek might be serious :-)

the list is sometimes strange - why 'replace has high priority, but 
other imo more important stuff has medium or low?

I think you are underestimating how badly REPLACE sucks. I wrote 
it, so I know it is as good as you are going to get in mezzanine. 
And it's a widely used and reviled function.

I expected such a comment on your part :-)

well, everything is important. But how much speed-up do we get via 
new replace? How often is that used in our code? :-)

I made it as best I could. It needs to be native.

I agree about the need for replace being a native. I would prefer 
emphasis on other areas though, e.g. on parse enhancements :-)

But - according to the list, it is hopefully being adressed too ...

If it didn't suck, it would be used a *lot*. This would be almost 
as much of a speedup as REDUCE/into and COMPOSE/into.

Parse enhancements are hard - have you seen that list?

yes, I had ... and? :-) Carl reserved 5 days for that. I am for implementation 
of all stuff from  the list. If you count the time needed, it is 
not more that 1-2 months to beta. After 3 years 1 or 2 months is 
OK with me ...

:)

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

Because there has not been any discussion or proposals for what those 
mezzanines should be yet. There isn't even any CuureCode requests 
for such - only a request to get CGI working on Windows (it already 
does on Linux).

I have no idea what mezzanines you would want for CGI support. And 
can't really test them except in simulation, due to Windows CGI not 
working yet. What do you want?

help cgi ;-)

It won't work the same way in R3 - no system/options/cgi object.

system/options/cgi

hmm - so where is the right place for such stuff?

Do we want to put it into external module? Then we are stripping 
out important stuff from R3, making it less compact than R2

hmm, Max lobbing for user dtypes :-)

Making a module, even a community library, is the best way to get 
the more complex stuff in. Post it to DevBase, start the discussion, 
get it refined, and then it may be incorporated, or may not be. Don't 
waste all of the work I did to get the module system working.

is there any new work version of REPLACE ?

The new REPLACE would be native, and noone has made any proposed 
source or even spec yet. Still under discussion.

BrianH: it is not about wasting. I just want we don't do fatal mistake 
- pretending we order users how they should use R3. R3 would be already 
used by many ppl, but is not, due of following reasons:

- missing network protocols, proxy
- call incompletness in comparison to R2
- weird console
- missing CGI mode
- missing DB protocols


No matter how your module system is usefull, if we don't provide 
users with R2 level completness, we are doing fatal mistake ...

CGI mode is only missing on Windows (and might be on OSX - noone 
has checked yet). CGI works just fine on Linux.