World: r3wp

I do know how to spell include just now hoe to type it !!

I thought there was a way that one could include one's own schemes 
in a binary .. but I never got it to work

You can use SSL in the cURL binding, but I haven't written scheme 
wrappers yet. Due to incomplete documentation, that's going to be 
a lot of work

Basically the same issues you had

Would Curl-to-R3 be able to solve the NTLM challenge that I have 
... similar to Graham's HTTPS for everything these days?

this doesn't work ? http://softinnov.org/rebol/ntlm.shtml

Graham I was never able to get connection using Doc's NTLM to IIS 
6.0.   Do did you have success with a Windows domain where you can 
display the login with a REBOL UI and then request information from 
IIS?

I've never tried NTLM .. suggest you contact doc

Thanks. Doc and I have had a series of discussions on it where he 
has helped me out. In particular was Cheyenne being able to pull 
IIS information authenticated to a Windows domain for presentation 
from Cheyenne. We got to ... some more detailed / dedicated Doc work 
needed because NTLM is tricky.   That's not an option now because 
Red is a priority for everyone including me.  But if Curl enables 
it ...

NTLM is a hard to support, even using OS API. Making my NTLM implementation 
work in all cases would probably take days (or even weeks) of research, 
tests and debugging.

A shorter road might be to port Python NTLM libs to REBOL.

cURL supports NTLM

There are two sides to R3 adoption for me. First is the available 
features. I greatly prefer to have basic schemes (HTTP and FTP in 
particular) built in. A basic GUI system is also important to me, 
but I can use R3 for non-GUI things without that. The second, and 
more important, aspect is stability and robustness. Is the module 
model stable, is it robust? Will tasks ever work? Are there outstanding 
core bugs that will prove problematic if they are never fixed. That 
is, if RT never did any more work on R3, could I use it for production 
work?

That's a matter of how much risk you are willing to take. R3 works 
quite well, but if you do hit a problem, it will be impossible to 
fix

Obviously, if work stops here, tasks will never work

The module model is stable for now, and has no current errors in 
the mezzanine code, though OSX has some errors in RESOLVE. When tasks 
are supported better there will need to be some minor underlying 
changes, but not many because the module system was written with 
the proposed multitasking model in mind. The module list hasn't been 
locked down from a security standpoint, though its layout was designed 
with that in mind. There are still bugs and missing features in the 
(UN)PROTECT functions that are blocking the locking down of R3, so 
don't run untrusted code yet.

The OSX builds keep running into compiler bugs which are tough to 
resolve. It's an ongoing process.

What's untrusted code?  Stuff I wrote ? :)

Stuff written by random people you don't know, like user extension 
scripts; R3 can't sandbox yet. For that matter, SECURE has been turned 
off since a109.

Can we compile R3 with our own schemes yet?

And if R3 stops now ... is there any advantage to R3 over R2 ?

Sure, either mezzanine or host-embedded extensions. And loadable 
extensions too, while SECURE isn't working.

And this is the main advantage over r2?

As for advantages, YMMV. For me, the improved PARSE, binary conversions 
that make sense, the map! type, the module system, the faster and 
more powerful loops, better error handling, and the increased consistency 
make R3 much easier to use. The extension model makes it more powerful 
- I always hated R2's library access model. But I don't do much GUI 
work in REBOL. R2 has database access that I use pretty often, and 
HTTPS support which I use rarely but it's important when I do. I've 
backported the most important missing functions from R3 to R2 in 
mezzanine form, though there is still some stuff I miss.

The improvements in 2.7.8 were pretty significant, so R2 is getting 
a lot more useful. I would love to have some kind of proper dialected 
binary conversion facility in R3 that could be ported back to R2, 
preferably compiled (generating conversion functions) - that would 
make it possible to have code like Red's compiler a lot more portable 
between R2 and R3, no explicit struct! use needed.

So, where to from here?

I can't invest any time in R3 without a fully working GUI and https

That is the case for a lot of people.

Between a rock and a hard place

With a rope dangling just out of reach.

That's good, then we can't hang ourselves ;-)

:-)

we wait 6 months or however it takes for Carl to get back to work?

Gallow's humour, we call that in Dutch

Same here Kaj.

Ah, didn't know that's also an English expression

0MQ is a wedge for me, between the rock and hard place. If I can 
use that for messaging, pieces can be (re)written in any language.

Yes

And also a danish: galge humor
where galge = gallows

Enough of the me toos!

I've already finished the major projects I was working on in R3 itself, 
like the module system; I can't start more without the protection 
bugs being fixed. My next stuff is all docs (modules and PARSE) and 
addons (that dialected binary conversion, plus maybe some schemes). 
What I really want to work on is Android, but I can start that work 
using Red for now.

I guess cURL solves the https

So, it's really waiting for the GUI team

It sort of solves it for me. We're spoiled with everything built 
into R2.

Has anyone tried making an R3 host that doesn't follow the standard 
program model? For instance, an application plugin?

Ok, to make it more usable .. we need to get the schemes finished

Any other show stoppers for the majority of users?

Was someone going to tackle the opendbx drivers?

We already have odbc, and a possible sqlite ...

I presume Linux users will want a native mysql driver