World: r4wp

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

World going offline for a while.

Retrofitting QUERY would be another alternative to READ/custom.

Change the signature of query to always include a mode field: QUERY 
target mode, then you could "default" read actions with READ, read 
actions with options with QUERY and the options as second parameter, 
write actions with options with WRITE.

I'd prefer using QUERY that way over READ/custom (or better, READ/args), 
which in turn I'd prefer over (ab)using WRITE.

When did this behaviour of rejoin change?

>> type? rejoin [ http:// "www.rebol.com" ]
== url!

>> rejoin [ now/date ]
== "17-Jan-2013"

It's behaving like ajoin for dates

oh .. perhaps it never worked like that for dates

Adrian, when make prep is run, prot-http.r is copied to host-init.r

tools/make-host-init.r is where the prot-http.r is included as well 
as all the others that are included into the binary

so looks like we can include our own protocols here

Ok, altering make-host-init.r to add schemes does add them to host-init.r 
but doesn't make the schemes available.  I guess they must be initialised 
somewhere else.

Everything seems to end up in boot-code.r

why is host-init.r checked in though, if it's generated?

mezz/boot-files.r ... add protocols here and they get included into 
the binary.
I managed to add a new scheme to the binary this way

So, looks like they have to be added in two separate files

Adrian, I would guess the directory was just uploaded to git

Aren't there also other autogenerated files on git

https://groups.google.com/forum/?fromgroups#!topic/Rebol/-s8WtukYj1E



You can also discuss here if you prefer, I posted it to GG in hope 
that even Carl might be able to see or discuss it there...

No interest to discuss 'Molding decimal numbers "precisely enough"'?

We just did a codecoverage check with R3 using the test-suite.

So, Andreas and I tipped a priori. So, what's your tip?

What is a "codecoverage check"?

(Just pure line coverage.)

The number of lines in the R3 C sources which are executed at least 
once while running the test suite.

aha, interesting

my estimate: 60%

I did expect that you like this Lad. Which give a good hint, what 
kind of test-cases are missing.

What were your estimates?

I estimated 20% (based on a perceiving the C sources to contain a 
high percentage of unused code).