r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Kaj
2-Feb-2011
[7375]
Brian tells me it should be possible to wrap cURL's features in R3 
schemes, but I can't make it a priority yet
Pekr
2-Feb-2011
[7376]
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?
Maxim
2-Feb-2011
[7377]
weren't there some problems with the code that someone trying to 
do their own schemes brought up? can't remember the details.
Kaj
2-Feb-2011
[7378]
Async devices would be very nice to do it properly, though
Pekr
2-Feb-2011
[7379]
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.
Kaj
2-Feb-2011
[7380]
I have doubts that scheme wrappers can support all efficiency tactics 
of cURL, but all REBOL scheme features should at least be possible
Henrik
2-Feb-2011
[7381]
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.
Pekr
2-Feb-2011
[7382x2]
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 ...
Maxim
2-Feb-2011
[7384]
threading is extremely important in real life apps which require 
performance.
Kaj
2-Feb-2011
[7385x2]
And simple responsiveness
If you have no threading and no async, you can forget multimedia
Maxim
2-Feb-2011
[7387]
exactly  ... and servers too.
Kaj
2-Feb-2011
[7388]
Servers such as Cheyenne can get by with multi-process
Maxim
2-Feb-2011
[7389]
but the real reason threading has to be done is because of the side-effects 
it will have on all the rest.
Kaj
2-Feb-2011
[7390]
Yep
Maxim
2-Feb-2011
[7391]
but threading makes a lot of things on a server possible which cannot 
be done *practically* using multi-process.
Kaj
2-Feb-2011
[7392]
Very high scalability, yes
Maxim
2-Feb-2011
[7393]
read access to shared memory is a big deal in handling sessions for 
example.
Kaj
2-Feb-2011
[7394]
Yes, I will eventually need that for an application server
Maxim
2-Feb-2011
[7395x2]
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.
Henrik
2-Feb-2011
[7397]
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.
GiuseppeC
2-Feb-2011
[7398]
Henrik, kust for curiosity. Which database connectivity ?PostgreSQL, 
MySQL ?
BrianH
2-Feb-2011
[7399]
ODBC?
GiuseppeC
2-Feb-2011
[7400]
ODBC? or ODBC!
Kaj
2-Feb-2011
[7401]
OpenDBX, I guess
Robert
2-Feb-2011
[7402]
At the moment we use SQLite and the goal is to use SQLAPI++ to map 
to all kind of backends.
GiuseppeC
2-Feb-2011
[7403x2]
Rober, will that work be open to the community or closed to RM Assets. 
Which licence model ?
The same question for R3-GUI
Robert
2-Feb-2011
[7405x2]
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.
GiuseppeC
2-Feb-2011
[7407]
So SQL Lite will be open too ? (I have seen, 249$ for SQLAPI++ is 
not so much)
Robert
2-Feb-2011
[7408]
Yes. I have a rough prototype but not in real-life use at the moment... 
step by step.
GiuseppeC
2-Feb-2011
[7409x2]
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.
Robert
2-Feb-2011
[7411]
We are working on it every day. And the speed is raising as a lot 
of base code has been done now...
GiuseppeC
2-Feb-2011
[7412]
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.
GrahamC
3-Feb-2011
[7413]
possible? worthile?

foreach [ a b c 3 d e ] list [ ... 3 = skip 3 elements ]
Cyphre
3-Feb-2011
[7414x2]
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 :)
Pekr
3-Feb-2011
[7416x3]
Cyphre - very good work, and good aproach too imo ...
WTF with ARM? Unbelievable :-)
Almost missed that note :-)
AdrianS
3-Feb-2011
[7419]
great to hear about ARM support - do you have any idea if this is 
just core or inc. graphics?
Robert
3-Feb-2011
[7420]
Just core.
Cyphre
3-Feb-2011
[7421]
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? 
:-)
Pekr
3-Feb-2011
[7422x3]
:-) 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 ...