World: r4wp

thanks, have that one in the candidates list as well

The time protocol mentioned in Vanity seems to need a change in design. 
There should never be a need for READ to have an /args option - that 
is what the path and query stuff are for.

Instead of this:
    read/args time://time.nist.gov [ GMT ]
it should be this:
    read time://time.nist.gov/gmt

`There should never be a need for READ to have an /args option - 
that is what the path and query stuff are for`


That's obviously problematic for systems which already make use of 
URLs including path and query components.

Are you talking about HTTP, the only scheme that has query and paths 
built into the URL spec standard? Because we have WRITE for that 
situation. For other schemes, we can define our own meaning of the 
query (and in some cases path) so we don't break the model.

read time://time.nist.gov/gmt implies to me that there is such a 
url when there isn't

or that they have such a REST service when they don't

write http://www.rebol.com[ HEAD ] is not a write but a read

Actually, it's sending a message to that server to which it is replying, 
but let's not quibble. We have other functions to get the head if 
you prefer.

I think you mentioned above that write should be used for non idempotent 
actions and read for the idempotent ones.

There are more port actions than just WRITE and READ. Don't limit 
yourself to just those two. Most of the metadata operations for HTTP-like 
schemes are handled by QUERY.

Or they would be if the scheme were fully implemented, as the http 
scheme in R3 is not.

Query doesn't take arguments except the port

And the mode, and it can take a url! or block spec. But there are 
other url! and port! actions than just those 3.

So, what should query do in the prot-http?

It's hard to know how things are supposed to be written when the 
only example we have is apparently incomplete

Agreed.

So, it's up to us to decide since no one else is going to tell us

There's a lot we can tell about the intended design by looking at 
the actions and their options. The actions were pared down deliberately, 
lowering overhead and getting rid of unnecessary options. Any action 
that can operate on a port is pert of the interface of ports, and 
the same goes for URLs. Plus, we have Carl's blogs and docs on the 
subject.

And we have people who discussed the design with Carl.

There are far more URL schemes which have defined uses for the path/query 
components.

Again, I think that adapting QUERY would be a nice alternative to 
READ/custom and give us a neutrally sounding general action.

The adaptation would be: make QUERY always take a second parameter, 
i.e. change from `QUERY target` to `QUERY target mode`. Let the MODE 
parameter be a block (or even unconstrained in type) to be used by 
the scheme implementation as seen fit.

Great news on all the crypto/TLS/HTTPS stuff guys!

Andreas, QUERY already takes a parameter, but it's optional. QUERY/mode 
retrieves a particular bit of information, and QUERY without /mode 
returns an object full of standard bits of information.

what exactly does mode do?

)
>> query/mode %tiger.png none
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

>> query %tiger.png
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

>> query/mode %tiger.png 'size
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

I think that it is supposed to act like GET-MODES in R2, but it might 
not be implemented yet.

Something scheme or type specific.

Andreas, QUERY already takes a parameter, but it's optional.

Yes, and I propose to change that.

I've always thought of QUERY as requesting metadata. READ is for 
content. If you, say, READ a directory (which I suppose I have no 
idea if it's still the way it works (tm)) to get all the files in 
that directory -- why would you use a different keyword to get a 
filtered list of, say files beginning with 'a'?

Where READ/args wins for me is that instead of, for example, composing 
a custom query string for HTTP -- you don't have to worry about that 
conversion. It's encoded and appended for you as defined by the port.

Compare:


 read join http://google.com/search?q=[url-encode a-query %&another-parameter= 
 "Foo"]

vs


 read/args http://google.com/search[q a-query another-parameter "Foo"]

read/args %folder/ [files beginning with "A"]

read %folder/a* :)

:P

Is there going to be a disputes resolution process here?

If Carl is not going to be here to arbitrate, are Saphiron's builds 
going to be the default?

Are they accepting pull requests? If not, then they won't be the 
default.

If they accept pull requests, they might have a shot of being an 
aggregator of development, like Linux maintainer repositories.

Anyone happens to know who we have as admins of the R3 project CureCode?

Or in a related question: what's the intended meaning of the "reviewed" 
status for R3 CC tickets?

We are (going to) accept pull-requests for our R3. IMO we need to 
move forward in those times where Carl isn't active.

Will you try to "sync" your changes with the "official" source in 
the future or let the sources diverge?

That's up to Carl. We will do pull-requests for our changes. But 
we are not going to wait.

Brian: Carl stated to me that QUERY was meant to return port state, 
not perform an action. But, I've never seen a final document that 
explains how R3 ports are supposed to work.

Gab, any idea of what the error is that corrupts the scheme after 
a forbidden read?

I'd have to review the code, the main problem with errors is that, 
again, port behavior is really not defined explicitly for that, and 
Carl never answered.

http://www.curecode.org/rebol3/ticket.rsp?id=1918&cursor=17

I have a PDF with the state diagram for HTTP, that may help you figure 
out the error problem. It's also possible that it was intentional 
in the sense that it is safer to initiate a new connection in case 
of error (though, some errors should be exceptions to this).

It corrupts the very next new connection