r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Schemes] Implementors guide

Graham
27-Jan-2010
[1862x4]
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 !
Gregg
27-Jan-2010
[1866]
I assume you reported it to them. :-)
Graham
27-Jan-2010
[1867x2]
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
BrianH
27-Jan-2010
[1869]
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.
Graham
27-Jan-2010
[1870]
eh??
BrianH
27-Jan-2010
[1871x2]
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.
Graham
27-Jan-2010
[1873]
I'm using the full path .. how can it break?
BrianH
27-Jan-2010
[1874]
It is better to make your script a module, and use local vars to 
store that kind of thing.
Graham
27-Jan-2010
[1875x2]
If i make it a module I have to export everything anyway
oh ... dear
BrianH
27-Jan-2010
[1877x2]
Not everything.
Every user script (including the one you linked above) is bound to 
system/contexts/user by default. Modules aren't.
Graham
27-Jan-2010
[1879]
just protect user then ...
BrianH
27-Jan-2010
[1880]
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.
Graham
27-Jan-2010
[1881]
So, if I set aside a couple of variables inside the module for these 
keys, how do I set them up automatically?
BrianH
27-Jan-2010
[1882]
In the module init code, or on first access, whatever.
Graham
27-Jan-2010
[1883]
So, are users supposed to initalize their email, passwords, proxies 
etc somewhere or each time they run a script?
BrianH
27-Jan-2010
[1884]
system/contexts/user is not initialized except by code. And "user" 
in this case doesn't refer to a person, but to a task.
Graham
27-Jan-2010
[1885]
Brilliant .. so where do we store such stuff?
BrianH
27-Jan-2010
[1886]
If you want to save prefs and then load them, cool.
Graham
27-Jan-2010
[1887]
So, every email script has their own prefs?
BrianH
27-Jan-2010
[1888x2]
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.
Graham
27-Jan-2010
[1890]
so where do we put our aliases ...
BrianH
27-Jan-2010
[1891]
%rebol.r
Graham
27-Jan-2010
[1892]
Ok, so is there an exemplar module that does things as you describe?
BrianH
27-Jan-2010
[1893x2]
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.
Graham
27-Jan-2010
[1895x2]
Anyway it's easy enough to fix once these things are standardized
I'll just do a search and replace on my scripts directory
BrianH
27-Jan-2010
[1897x2]
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.
Graham
27-Jan-2010
[1899]
Again we await the exemplars from Carl ...
BrianH
27-Jan-2010
[1900x2]
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.
Graham
27-Jan-2010
[1902]
Ok, I'm confused .. i see Gabriele's prot-http says it is a module, 
but there is no exports
BrianH
27-Jan-2010
[1903]
It doesn't export anything - it doesn't need to.
Graham
27-Jan-2010
[1904]
the reason being ?
BrianH
27-Jan-2010
[1905x3]
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.
Graham
27-Jan-2010
[1908x2]
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
BrianH
27-Jan-2010
[1910]
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.
Graham
27-Jan-2010
[1911]
That presupposes that there is no reusable code in the modules