World: r3wp

is carl even aware that there is a cURL binding right now and that 
maybe he can skip this for now?

I don't like the fact that Carl does not discuss the direction (beta 
list) with the group ....

Carl has handled cURL related bug reports, but chances are he doesn't 
know what it is :-)

in any case a tool like cURL is always going to be better since its 
being developped using standard tools which evolve and keep pace 
with changing specs and are bug fixed on their own.


I'd rather that we be able to wrap cURL within schemes properly and 
that they be fixed or enhanced to make it happen.

the core already has enough features... we need more architecture 
work and polishing.

Maxim - I don't necessarily agree. I would not like to see us departure 
from REBOL port model. I still think, that in the long run, protocols 
should be done directly in REBOL.

We already have a working prototype for a native SSL/TLS implementation.

Henrik - you mean from R2?

wait... I retract "working". I've not read the code, but Cyphre has 
done it a few days ago.

Pekr, no a new implementation.

pekr, as I understand it the system right now needs to be updated 
in order to allow external developpers to properly integrate into 
the port/scheme model.


would be nice that this be addressed so that Kaj could have already 
done it.

Brian tells me it should be possible to wrap cURL's features in R3 
schemes, but I can't make it a priority yet

I thought so - so it is a RMA stuff. And Carl most probably taking 
an easy route of finish R3? I hope this is not going to be an extension, 
but that encryption ports are part of kernel?

weren't there some problems with the code that someone trying to 
do their own schemes brought up? can't remember the details.

Async devices would be very nice to do it properly, though

Maxim - no, it was just Graham doing port schemes. Carl was supposed 
to revise them for inclusion or something like that. Graham gave 
up, as typically no feedback was received.

I have doubts that scheme wrappers can support all efficiency tactics 
of cURL, but all REBOL scheme features should at least be possible

Pekr, I don't know the deep details and I can't access the source 
(SVN trouble), but I can see one of the goals being that some parts 
are logically implemented in REBOL, because that makes them easy 
to maintain, rather than sifting through C code.

But - I am all for architecture related stuff - so e.g. security, 
improving extension mechanism including devices, new streamed codec 
model, threading (not because I think it is important, but because 
I think that it might have some implications on how some underlying 
stuff is organised)

I would really welcome, if Carl would start to communicate, not cutting 
the rest of the community off. Seeing last R3 related blog or Twitter 
message dated back to November really makes bad impression ...

threading is extremely important in real life apps which require 
performance.

And simple responsiveness

If you have no threading and no async, you can forget multimedia

exactly  ... and servers too.

Servers such as Cheyenne can get by with multi-process

but the real reason threading has to be done is because of the side-effects 
it will have on all the rest.

Yep

but threading makes a lot of things on a server possible which cannot 
be done *practically* using multi-process.

Very high scalability, yes

read access to shared memory is a big deal in handling sessions for 
example.

Yes, I will eventually need that for an application server

it also saves on RAM, and I could do multi-processing liquid nodes, 
for example... right now its impossible to do.

or rather currently *unsafe* since the thread model in R3 has some 
limitations.

I can see that, and I'm not sure when work on threading will start 
or if Carl is studying it behind the scenes. All I can see is that 
many things right now are being handled on RM Asset needs, which 
right now is very focused on bringing certain tools to life. In that, 
there is work on GUI and database connectivity.


The SSL discussion was initially brought up by Cyphre as he talked 
about his prototype (which I now read is in fact done in R2, sorry). 
Carl gladly accepted this and asked for specification on what needs 
to be implemented natively to make it all work.

Henrik, kust for curiosity. Which database connectivity ?PostgreSQL, 
MySQL ?

ODBC?

ODBC? or ODBC!

OpenDBX, I guess

At the moment we use SQLite and the goal is to use SQLAPI++ to map 
to all kind of backends.

Rober, will that work be open to the community or closed to RM Assets. 
Which licence model ?

The same question for R3-GUI

R3-GUI is open.

SQLAPI++ is a commercial lib. The extension for R3 will be available. 
If the source as well I don't know yet. This depends on what we use 
internally.

So SQL Lite will be open too ? (I have seen, 249$ for SQLAPI++ is 
not so much)

Yes. I have a rough prototype but not in real-life use at the moment... 
step by step.

In the last months I have changed to passive mode. Too many changes 
from everywhere...

So when GUI and SQLite will come they will be welcome.

We are working on it every day. And the speed is raising as a lot 
of base code has been done now...

Robert, since RM Assets has put some on their future project on REBOL3 
things are going at light speed. Your choise has been a risk for 
your company because you put some important applications on a alpha 
project. (R3). Thanks in advance from everyone.

possible? worthile?

foreach [ a b c 3 d e ] list [ ... 3 = skip 3 elements ]

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.