World: r3wp

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.

Also, to bring some positive news...one note from Carl: "So, just 
an FYI, R3 is running on ARM now." I thought most of people here 
wanted to hear such thing :)

Cyphre - very good work, and good aproach too imo ...

WTF with ARM? Unbelievable :-)

Almost missed that note :-)

great to hear about ARM support - do you have any idea if this is 
just core or inc. graphics?

Just core.

I bet it is just core because so far there is noone who would like 
to port graphics to Linux. What would you Linux guys do without Wine? 
:-)

:-) Without Wine? Just whine :-)

But as for "just core" argument - does it mean including the host 
kit part? I mean - did Carl manage just to compile Core under ARM, 
or is it runnable R3 without graphics?

Well, maybe "R3 is running on ARM" speaks for itself, that's really 
nice if at least Core works ...

hopefully then 'BEIN' will follow soon...

> What would you Linux guys do without Wine? :-)
Live happily ever after? :)

I live happily without it on my own Linux distro. Prevents a lot 
of frustration to be able to say to people that you can't run Windows 
software :-)

For the record, I do want to port R3 graphics to Linux, but that 
doesn't mean that it's possible or wise. It's not possible due to 
fulltime work on other R3 stuff, and it's not wise because the Amiga 
patches haven't been integrated yet, so the host kit is still very 
Windows oriented while more work has already been done

May sound stupid, but I agree :)

Looking into porting R3 graphics to Linux has been on my "if you 
ever come across a free week" list for a while.

I've also asked Steven Solie in public and in private to put up his 
Amiga patches somewhere, as this will definitely help everyone interested 
in doing the same for Linux.

Yeah, and you'd be spending that week redoing Steven's work in the 
current situation