World: r3wp

So, I have some bugs in my scheme?

and remote commands too

well, missing lot of commands :)

oh yeah ...minimal functionality ... for someone else to finish ;)

cwd: func [ mbox [port!] dir [string!]][
	if in mbox/scheme/actor 'cwd [
		mbox/scheme/actor/cwd dir
	]
]

which is what I have in my imap scheme ... could use similar for 
ftp

actor: [
	cwd: funct [ dir [string!]][
			write mbox compose [ SELECT (dir) ]
			read mbox
		]
]

i'm doing differently currently, i only use WRITE to pass block of 
commands to parse

so the user still has low level access to the scheme or not?

don't know what u mean exactly, so i would say... maybe

the user can still use the port in what carl calls mixed mode ...

OPEN, WRITE and CLOSE will be the only one usefull actors in my scheme

I think mine allows file upload resume by sening a APPE command with 
the rest of the file

but rather than handling it directly ... you can just write the command 
to the port

a session will be something like:
>> session: open ftp://ftp.site.com
>> write session [
	USER "toto"
	PASS "****"
	PASV
	BINARY
	CD /dir-temp
	GET %thif-file
]
>> close session

ok, looking forward to seeing it ...

and i will use a dialect to construct the state diagrams

for example, the state diagram used to open a ftp session looks like 
this currently.

USER
<< ( 
	(1 2) error
	(4 5) fail
	3 >> PASS << ( 
		2		success
		1		error
		(4 5)	fail
		3 >> ACCT << (
				2   	success
				(1 3) 	error
				4 5 	fail
		)
	)
)

it's a dialect

Nice ...  I'm looking for a dialected flow control GUI tool too :)

This one, to rename a file:

RNFR ;** rename a file.
<< (
	(1 2) error
	(4 5) fail
	3 (
		>> RTNO
		<< (
			2	success
			(1 3)	error
			(4 5)	fail
		)
	)
)

I'm wondering how to interface with Amazon's simple DB.

Both Maarten and I passed the secret and access keys as parameters 
to the various functions, but I think I'd rather have a system/user 
object to store them and use them from there.

So, can we have an extensible system/user object that we can store 
user related data for use in schemes etc ?

system/contexts/user is user-specific, and schemes can store their 
data in their modules if they like.

I don't think we're going to get back system/user - all global options 
are going under system/options, including options about users.

You need to make sure that your data is task-safe too, so changeable 
global options are usually bad unless they are changed through a 
function that synchronizes access. system/contexts/user is task-specific.

Don't know whether system/options will be task-specific - most of 
its options are supposed to be read-only.

The writeable options like binary-base are supposed to be moved to 
on-the-spot function options.

so, it's system/contexts/user/user ... we can store a user object 
here?

And set-net will store the data here too?

system/contexts/user is the script context. You can put whatever 
script-accessible words you want there.

We are using modules and access functions like set-net instead of 
global options objects, for the most part.

The system structure of R3 is very different from R2.

I think we can work with everything being in system/contexts/user/user 
for the purposes of a scheme for the moment

Remember that 'user is a common script word, so that will be overwritten. 
Use module-local data, or port-specific data.

Eh?

Certainly, set-net shouldn't set anything writeable any other way.

Moving on .... an AWS:// scheme can certainly be derived from the 
http scheme

system/contexts/user is the shared "global" context for all user 
scripts (not modules), and that's why it's task-specific.

Maarten did so for Qtask, so I assume that strategy for aws:// would 
work here.

Umm.. he rewrote the http scheme I think

Yeah. Which we need to do too.

Eh?  What's wrong with Gabriele's http scheme?

Anyway, Maarten had to do all of this because he chose to use the 
REST method of interacting with aws.  To it seems much simpler to 
use SOAP instead.

Chunked encoding is broken, which is why the released version has 
been modded to use http 1.0; error handling is broken (the source 
of most chat errors); no server support; written for an older idea 
of R3 semantics.

Our HTTP scheme should work with REST out-of-the-box too.

I haven't used the prot-http ...

Is Gabriele ever coming back to work on any R3 stuff ?  Or is he 
a permanent qtask person now?

It's next on my list after 2.7.8 and R3 compressed modules/scripts.

Yes, I'm sure it will work with REST ... it's just harder to maintain 
the aws interface each time they change their specifications