World: r4wp

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

so possibly something in the http scheme object ?

very likely, the port needs to be reset after the error. perhaps 
a QUERY does it. I don't remember.

I posted the diagram in the files here.

Hmm.  The port is anonymous

Yes, those diagrams look the same I think as on the rebol.net wiki

ah, you're right, then there must be something that is global and 
should not be.

which is why I was thinking the scheme object

because it reports the same error

maybe i'm using a block or object somewhere without clearing / reallocating 
it

Oh well, if you have some spare cycles

i'll keep this in mind, but this month is very busy here.

Anyone happens to know who we have as admins of the R3 project CureCode?
 Carl, BrianH and me.

Who decides an issue is closed?

Who can re-open issues?

what's the intended meaning of the 

reviewed" status for R3 CC tickets?" It means that the ticket has 
been acknowledged/accepted and will be processed. At least, that 
was the initial meaning, maybe Carl and Brian used it differently 
afterward.

Who decides an issue is closed?

 Depends on the convention set for R3 project. I usually consider 
 that it should be closed by the developer processing it, once the 
 issue is fixed. It could also be closed by the one that opened it 
 if he's satisfied by the provided answer or the fix.

Who can re-open issues?

 Admin can, Developer should too. Currently in addition to admins, 
 there are 3 people with Developer roles/rights: Henrik, Cyphre and 
 Gabriele.