World: r4wp

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.

You have to see it in terms of the whole model. READ and WRITE don't 
just operate on HTTP and files, they can operate on a wide variety 
of port types.

An HTTP POST is not a read, for instance, it's more like a write 
because it is supposed to have side effects.

I agree with that.

I'm not sure how removing read/custom (or renamed read/args) has 
any bearing on other types...

Where for HTTP (or my sandbox port example above), it is actual functionality 
that is lost.

SOAP requests are often GET

SOAP's behavior is considered to be bad, as far as HTTP use is concerned.

There was a proposal to enhance READ with something like an /options 
or /types option, I can't remember which, but it's not in CureCode. 
It was Carl's idea, but it might be in a blog, chat or another AltME 
world. I only remember it because I was waiting for that feature 
to enhance the clipboard scheme's handling of other datatypes.

It severely restricts what you can pass to the scheme actors without 
any suitable refinements

Don't see it on the blog.

WRITE is as unrestricted as READ/custom was. One of the ways that 
R3's port model was sped up was to restrict the number of options 
passed to the actions.

/options is better than nowt, but I'd maintain a /params (/args) 
refinement would be beneficial to at least a few different schemes.

The /options refinements was one of the proposals for standard function 
options; /into was another such proposal. You'd have to look in R3 
chat for details.

read/lines passes thru .. so I'm not sure what you're saving but 
not allowing /args

Looked in chat #1097 (the area where standard options were discussed) 
and we haven't brought it up there yet, but Carl did a blog about 
it.

uRL?

No idea, I just remember him doing so.

The main subject of the initial /options proposal was MOLD, to replace 
all of the MOLD-related system/options settings.

Still haven't found it -- just another point where you were waiting 
on changes : )
http://www.rebol.org/aga-display-posts.r?post=r3wp771x2326