World: r3wp

In the future in R3, the code itself will be bundled with R3, but 
if you fire up R3 and type decode-cgi, it won't be available straight 
away. You'll have to explicitly import the CGI functions with import 
'cgi first.

do you use rebol without networking or db protocols? what for?

Yes. Many different scenarios. I have never used REBOL's ftp protocol, 
for example.

And obviously there are many REBOL scripts which will never need 
the CGI stuff :)

Pekr, I believe this is not just for distribution purposes, but for 
allowing R3 to start up faster in certain cases, not having to initialize 
various protocols, etc.

And to reduce clutter in the "global" default namespace.

The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?

Gregg, same response to you: nothing will be excluded. Just not imported 
by default.

And you can do imports in the header, or on a single line.

and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.

IMPORT with a block! as argument does the same as the NEEDS block 
in a header.

Right, what I don't want is to have to explicitly import "basic functionality" 
in every script. The question is what is basic? And while we can 
certainly do it in a single header line, that's far from the same 
as having it "just work". 


I just want to make sure we're saving enough to make it worthwhile. 
You know how I hate premature optimization. ;-)

That's precisely the point: what one considers "basic" functionality 
varies widely :)

I think the point of the public release of this effort is to collect 
what you want (or not) as default.

And some simple modularisation helps everyone, in the end.

Right, so where is our list of options and dependencies?

Heh, _compiling_ that list of options and dependency is part of the 
work in progress, I think :)

So we know if we allow a url! as an arg we're sure to get all the 
protcols that are supported for any url! we might get.

Yes, and that task is important.

I wouldn't say so. Those functions which process urls must ensure 
that the protocols they need are loaded.

(Just as READ, OPEN, etc will have to do internally.)

Not sure I want to think about what those simple, generic, rebol-leveraging 
funcs might look like. Still, I'll keep an open mind. Show me the 
benefit and let me count the cost.

If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.

Sorry, "weigh their value" should be "evaluate their cost".

$ rebol3 --do what | wc -l
480

(-3, because of some useless startup output.)

so rebol3 is worth 480$ ?   ;-)

+ all schemes (currently only http is bundled with R3), + all functions 
which are not yet bundled in R3 but where available in R2 (cgi, html), 
+ modules which might be worth bundling (database?)

I guess the first step will be to go through these 480 functions 
and group them into some basic modules: possibly core, extra, math, 
debug.

extra == "plus". In a recent CC bug Carl for example mentioned having 
LAST? in core and moving SINGLE? to plus, if it is still wanted.

(And note that all "plus" functions will still be immediately available 
per default.)

I am fully with Gregg here. At least http(s), ftp, smtp, pop, could 
be allowed by default ...

I often use those protocols in console, and I don't want to become 
'import monkey ...

well voice, your needs on the web  ;-)

hum... the comma there makes the sentence a bit weird... ignore it...

Pekr, import [http ftp smtp pop] is tough typing, for sure.

And as I mentioned above, most likely READ will do the import automagically 
for some "blessed" internal modules.

there will probably be shortcuts like import_plus  import_full.

Maybe a pseudo-module named 'full, then import 'full will do.

And I'm sure there'll be a way to just put the import in user.r/rebol.r 
and be done with it.

Andreas, while the typing is simple, do you agree that you aren't 
just going to type it once, and that there is a cognitive overhead 
to defining the imports?

I agree.

Again, I'm not necessarily against it, as long as there is a benefit. 
If the benefit is 3ms faster loading and 30K less memory consumption, 
I will probably say that my time is more valuable than that. :-)

3ms would be a startup time improvement of over 10%.

In a CGI use case, that is _definitely_ worth it.

It wouldn't help a CGI script, because it would need to import CGI, 
HTTP, HTTPS, ... ;-)

Don't be that anxious about your console. Once modularisation is 
done, it is ridiculously easy to get back a REBOL console with all 
modules and then some enabled and ready to use just like nothing 
ever happened.

It is the other way round that is hard.

It would help a CGI script a lot, because it won't have to import 
20 network protocols it never uses. But I sure noticed the ;-) at 
the end :)

Oh to have to complain about the overhead of 20 standard network 
protocols...<wistful sigh>


But I take you're point, if my CGI is called hundreds of times per 
day, it adds up. ;-)