World: r3wp

So if a user script did user: "Graham" to a top-level variable in 
their script, your AWS script would break.

I'm using the full path .. how can it break?

It is better to make your script a module, and use local vars to 
store that kind of thing.

If i make it a module I have to export everything anyway

oh ... dear

Not everything.

Every user script (including the one you linked above) is bound to 
system/contexts/user by default. Modules aren't.

just protect user then ...

Then you would break a lot of code. If you protect/hide 'user and 
then don't use the full path to access it, just direct word access, 
then subsequent user scripts that use 'user will use a new variable 
called 'user that isn't the same as yours.

So, if I set aside a couple of variables inside the module for these 
keys, how do I set them up automatically?

In the module init code, or on first access, whatever.

So, are users supposed to initalize their email, passwords, proxies 
etc somewhere or each time they run a script?

system/contexts/user is not initialized except by code. And "user" 
in this case doesn't refer to a person, but to a task.

Brilliant .. so where do we store such stuff?

If you want to save prefs and then load them, cool.

So, every email script has their own prefs?

We are still planning to add some common code to put preferences 
in %user.r, instead of the code that goes there in R2.

The trick is that %user.r would only contain preferences, not code. 
Putting code in a user-writeable script is not very secure.

so where do we put our aliases ...

%rebol.r

Ok, so is there an exemplar module that does things as you describe?

Which doesn't get loaded from the user directory. If you want your 
%rebol.r to load user scripts, go for it.

I am not aware of any R3 scripts that do emailing. The details of 
the preferences infrastructure hasn't even been discussed yet, except 
for undoing the old behavior of %rebol.r and %user.r and replacing 
them with something secure. In general, "our aliases" are put in 
a module that you import if you want to.

Anyway it's easy enough to fix once these things are standardized

I'll just do a search and replace on my scripts directory

The real trick is that R3 network protocols should be put in modules, 
not scripts. Otherwise there won't be much code sharing.

Scripts are for end-developer apps, not infrastructure.

Again we await the exemplars from Carl ...

This is all mezzanine stuff. We don't need to wait for Carl.

We only need Carl's help with native stuff. We could use his help 
with certain other activities that he's good at, but we don't *need* 
it.

Ok, I'm confused .. i see Gabriele's prot-http says it is a module, 
but there is no exports

It doesn't export anything - it doesn't need to.

the reason being ?

Once the protocol is installed then you just use OPEN, READ and WRITE, 
etc. directly. You only need exported helper functions for some protocols, 
but http is covered by the default actions.

For instance pop or imap might need a SEND-EMAIL function exported, 
and maybe a SET-NET. That's all.

I'd be wary of using a SEND function until we really know what the 
services infrastructure is going to look like.

So, any function which takes a port as an argument inside the module 
( if it is also a scheme ) does not need exporting.

The rest we have to access via the module path

Nope, not even then. Most protocol functions don't have to be accessed 
from the outside except by the port infrastructure. Functions in 
the scheme are only called by port infrastructure, and most functions 
are helper functions. The only words you export would be user-visible 
functions that users are supposed to call directly.

That presupposes that there is no reusable code in the modules

In general you never access a word through a module path. If it needs 
to be user-accessible, export it or wrap it in a function that you 
export. System accessible is another matter, and usually involves 
installing something somewhere in the system hierarchy (like system/schemes, 
for instance).

No, it supposes that you are refactoring your modules so that the 
reusable code is getting exported from a reusable code module, then 
imported into your specific module.

The module author can not possibly know what users might want to 
reuse

Then provide the source. Making things safely reusable takes planning. 
Providing the source doesn't (or at least not as much).

Say I wanted to create a http header, I would naturally want to use 
Gab's make-http-request function that is not exported

Say you wanted to create an HTTP header, and it had nothing to do 
with HTTP. Are you sure you want to create the same header? Or are 
you sure that you don't actually want to extend the existing http 
scheme? The author isn't psychic.

Making code reusable takes planning. If you want to reuse code safely, 
do the planning. Or copy and paste.

And we arrive at a situation where you end up duplicating code everywhere

Not really. You could do the planning, and refactor. Even Gabriele's 
code, since he provided the source.

But we lack the sources to recompile the core with our refactored 
code