World: r3wp

SOAP looks much easier to implement compared with the tricky stuff 
you have to do with REST.

I haven't looked at the other services for a while now, and don't 
think I ever looked at the SOAP api for S3, and SQS .. but I suspect 
it's very similar, and just point the URL to a different service

What would be nice would be a small tight library for dealing with 
basic XML

Not suggesting that anyone write an XSD parser!

Start with simple, well-formed XML, and go from there.

I was wondering about TFTP but see that it is based on UDP .. oh 
well...

TFTP is funny, I have a R2 TFTP server impl lying around, somewhere

There's also a get in the library http://www.rebol.org/view-script.r?script=tftp-get.r

as well as a BOOTP server. also UDP, though

so the bootp is for a rebol os ?

heh

bootp+tftp is sufficient to netboot some machines

http://msdn.microsoft.com/en-us/magazine/cc188797.aspx


DIME extension for SOAP ... dunno, doesn't seem as simple as they 
make out

any revision to current schemes by Carl? Was supposed to be done 
... "overnight", no?

I haven't heard anything back

I see that Sun  has their cloud service though it is in beta testing. 
 They have a huge datacentre ... something like 3 football fields 
long ... dunno what sort of football though

They are using Webdav and also RESTful APIs similar to those from 
Amazon S3

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