World: r3wp

Can't find any pricing information though ..

I managed to get SQS working using SOAP ( I create the message with 
r3 and then send it using r2 as it needs to be over https ).
But keep getting server errors when trying to work with S3

Got it working with S3 .. there's a bug in the Amazon Soap service 
for S3 which I uncovered !

I assume you reported it to them. :-)

Yes, filled in their feedback form.

Updated the AWS stuff so that you can now create messages for S3, 
SQS, and SDB.
http://rebol.wik.is/Rebol3/AWS

You should make it a module so the local vars get stored somewhere 
other than system/contexts/user/user. The word 'user is commonly 
used in scripts, and any one of those would break your code.

eh??

system/contexts/user is the main context for user scripts. Like yours, 
for example.

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).