World: r4wp

Once we manage to integrate the algorithms in form of natives it's 
just matter of adding the other cipher suites handling into the current 
TLS scheme.

compatible are GPL, MIT and Apache?

GPL? really?

that's what I was asking .. robert seems to say yes

I prefer BSD or public domain or suctom 'free' licenses as there 
I'm sure noone will complain I've stolen the code. In other lic cases 
I have no experience.

If GLP is acceptable then things would be easier. (I've seen some 
nice GPL implementations) But I'm not sure GPL code can be used for 
encapping?? But as I said I'm usually lost in the licensing stuff 
;)

I'd think GPL is out

Even Apple has a sha256 open source version out there

BTW getting the TLS/HTTPS to run on Android proves that our solution 
is good and can be easily used in crossplatform way. No need for 
any OpenSSL-like bloat anymore in R3 ;)

I haven't searched for SHA256 yet so that is possible. I'm now looking 
more for the DH and 3DES...

GPL not

One more note: AFAIK the current version of TLS + the encryption 
support increased the binary only by ~10KB which is also cool. I 
have no clue how much could take adding the rest of missing algorithms 
though.

http://www.codeguru.com/cpp/misc/misc/cryptoapi/article.php/c8195/Portable-Cryptography-API-for-Triple-DES.htm

C and C++ implementations

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?