World: r3wp

why SSL and encryption?

Carl should get beta list out, not just choose another priority for 
next 3 months and then disappear again ...

Because there is a process of determining how it should be done and 
it might make sense to prepare for it now. There are several possibilities 
for implementation.

really, if we have to choose between encryption and threads... there 
is no contest.... all the "usability" stuff we can code as extensions 
and indeed, the cURL binding is a good example of this.


we need threads to be done... they have an over-arching effect on 
every aspect of REBOL... we can't put this off until later... its 
going to change the design of things for sure.  I can't understand 
why Carl is side-stepping this again.

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.