World: r4wp

As you can see, there's no error handling yet .. I thought there 
was a field in the scheme object to store errors but I've lost it.

Pavel used a read/lines to format the date in local date format. 
 I replaced that with write options

So, you can 

read time://time.nist.gov to get the date

or

write time://time.nist.gov [ GMT }

to get the date back in GMT.

We kept the http-error from Gab's prot-http.r until we figure out 
what to do about errors

Read/Write appears to be awkward -- is there any planned replacement 
for read/custom?  I'd suggest that read/args (or read/params) would 
make more sense than write in the above example...

Well, currently 'read doesn't have a custom refinement.  But I guess 
that can be added and then we can use that.

I know, I'm just hoping there will be...

But why would you want to diverge from R2's read/custom in favour 
of read/args?

Could be quite elegant used alongside codecs.

Args (params, whatever) is more specific. read/custom is a bit woolly.

where is 'read defined?

Just searching the sources now ...

https://github.com/rebol/r3/blob/master/src/boot/actions.r

So, is it just a case of adding the /args or whatever refinement 
there?

Should get some concensus on this as it will affect all the schemes, 
and may need a little rewriting of the http scheme which uses write 
to pass options

I certainly see a read/args as being quite distinct in purpose from 
write.  I use it with my sandbox scheme (http://reb4.me/r/wrt) to 
filter directory contents.


 read/custom wrt://system/ [thru %.r] ; shows only rebol scripts in 
 this folder
	write wrt://system/ [thru %.r] ; means something else entirely

On the http scheme, it could be the difference between adding a query 
string to a GET request (read/custom), and adding post data on a 
POST/PUT request (write).

with read you're expecting some content back, with write, you're 
not

Should we even use write in the http scheme?

I'm appreciative of a return value from write. For example, on a 
hypothetical Twitter scheme, write twitter:// "My Tweet" would return 
the new tweet id.

Similarly most http write operations return a value of some kind.

so, the http scheme should stick to read for sync ops

I see read/get as synonymous, write/post or put, delete/delete.

and HEAD ?

info?

the thing is that GET sends information and gets something back. 
 Same as POST.  What's the difference?

Intent.

Content.

But are we expecting the casual user to understand this?

I believe it's more consistent.

A casual user of http, for sure : )

So, if you're reading a HTTP form, you can either use GET or POST 
 ....

So, what is the user supposed to do ... use READ or WRITE ?

GET/READ, POST/WRITE.

Sounds like duplication

the http scheme author has to then support both methods of doing 
the same thing

Not at all. Particularly if you consider the HTML form -- GET sends 
parameters in the URL, POST sends parameters in the body. And consider 
the usage of each: GET is usually some type of search/filter facility, 
POST is sending data to be stored.

Well, I usually use POST to collect a token to allow me to proceed 
on the site

People don't like sending passwords in the URL

For a developer, the intent is far clearer.

	read/custom http://google.com[q "Gordon Strachan"]

 write http://my-site.com[title "A Blog Post" content "Today I..."]

It would be simpler if we just used 

GET and POST instead of read/write

Looks like it's time to setup one's own r3 build environment to test 
these things out

Graham, would you prefer have functions for all HTTP methods (get, 
post, put, delete, head, options, trace, connect) ?

btw, is boot/host-init.r not meant to be used? Seems to be pretty 
much identical to mezz/prot-http.r minus the header. Is the first 
produced from the latter? If so, why is it checked in?

The last question is addressed at anyone who'd know...

Adrian, the actors are used to provide a series abstraction on ports. 
 But as developers I think it might be clearer to have specific methods. 
 Otherwise you're reading the options block to see exactly what is 
being done.

though I guess we can always put wrappers around the read/write

Chris, WRITE dest block is the replacement for READ/custom.

Graham, HTTP GET is supposed to be repeatable without side effects, 
and thus safe to cache. HTTP POST is supposed to generate side effects, 
and thus not be safe to cache.

I welcome the change to Write, but lament the change to Read. Even 
if they appear the same, I see them as having semantically different 
objectives.