World: r3wp

when rebol came out it was hands down the best parser implementation 
out there... 10 years later the rest of the industry is catching 
up to it.  We've pushed it a little further again.

I know that me and Brian don't always see eye to eye but I'm an honest 
person where Christ has a say and I am humbled to acknowledge that 
Brian is instrumental in some of the greatest achievements of REBOL 
to date and see him as the REBOLer of the YEAR!!!!! if there were 
such a reward!

there is such a reward, vote for him in the user.r group ... right 
here in altme  :-)

I agree Maxim but now REBOL is far superior on the playing field.

Thanks Maxim.  I shall.

and yes, Brian has put a lot of his time into R3 for free.  He has 
been pushing and helping Carl into doing a lot of things which are 
now part of R3.  He deserves our gratitude.  h might have shaven 
a full year off of R3's implementation just by himself.

I agreee Maxim.  I don't always agree with BrianH on my issues but 
when it comes to Parse, I have been dead on with his ideas.

Thanks Brian.

+1

Thanks :D

Seriously, we owe a lot to Peta. PARSE is much better because of 
Peta's work. A bit of a drive-by though: Came, argued well and helpfully, 
then disappeared. I look forward to the next time Peta shows up :)

We owned general-purpose parsing until Perl 6 started catching up. 
We have surpassed them now though :)

Is anyone still using Perl? :-) In the world of PHP, Python, Ruby 
hype? :-)

Wonder where Peta is, though ....

Nice to read you working on the host code together with Carl. Hope 
in a couple of years I'll be ablet to do this too :-) You are a good 
group.

Howevere PARSE is still not complete: REVERS is the only thing I 
miss. However, If we must judge, 95% of work on PARSE is done and 
only 5% is missing.

REVERSE, OF - those are probably left fro 3.1 or later, because they 
are more difficult to implement. We should not thing about R3 development 
being stopped by reaching 3.0 release :-)

I think so. Carl  won't open PARSE rebol code again once it reached 
this stage.

REVERSE, LIMIT and OF (but renamed I hope) are still on the todo 
list, and I really want all of those. My biggest pie-in-the-sky requests 
have been done though (with the exception of USE, which I have a 
workaround for).

Back to discussion of priorities, we shouldn't delay release because 
of those missing operations.

It is triage time, my friends. We are heading to beta, so we need 
to seriously consider what it practical to do quickly, and what needs 
be put off for a bit. REBOL is going to continue to have reasonably 
frequent updates - no more waiting years for the next release - so 
you don't have to act like your favorite proposed feature will never 
arrive if it doesn't make 3.0. We need to figure out what we need 
to make a useful beta.

Infrastructure first, please. That means - as much complete Core 
concept-wise, as possible - Tasking, enhanced extensions, Console 
for Windows, parallel work on View engine, so that 3.1 can come 3-5 
month after 3.0, including initial VID3 release, sound.

REBOL 2 will still be here, and despite what some people have been 
saying it hasn't been abandoned. We have been focusing on R3 lately, 
but there will be new R2 releases to come. Migrating to R3 won't 
be an all-or-nothing affair. Gradual migration and mixed projects 
may be the norm for the short term. We don't want to block our users 
from uusing the killer features of R3 just because it doesn't do 
everything R2 does yet.

This means that we won't be putting off the R3 beta until we reach 
feature parity with R2. In many ways we have already surpassed R2, 
but there will be some things missing in this round (VID). If you 
need those features, keep using R2 for that portion of your project. 
The new GUI won't be compatible with the old ones anyways, so you 
might not want to delay starting migration because you may want to 
rewrite your GUI later.

Did not know this doc got updated :-) http://rebol.com/r3/docs/project.html

BrianH: I think that everybody here understands, that we aim for 
3.0 Core release. But even that one needs to be feautre complete. 
I would really like, if Tasking for e.g. would be there, because 
it CAN influence some modules, mezzanines or even natives. This is 
fundamental feature to have imo, and some devs (Doc - Cheyenne) are 
waiting for it. Then add back console. CGI under Windows was solved, 
Netwokring protocols are going to be adressed hopefully soon too 
:-)

Yes, project doc updated. But, some priority changes are happening.

The main change is to move HOST Source to a higher priority.

Nice overview. Especially how long it took you. Give some "benchmark" 
on productivity.

Hi Robert, yes, it is indeed interesting "where the time goes".

Btw - for future, to speed up some developments, I propose the bounty 
system - http://bounties.morphzone.org/.... we would just need to 
define few rules, e.g.:

- the ability to merge bounties

- the ability to predefine possible implementator - not everybody's 
code can be realistically accepted, etc.

I think that that way we can speed up some developments too ...

Hmm - interesting note in http blog comment section - what abot https? 
We never touched that area. Or maybe once, when Max suggested to 
look for Putty code. We need https surely too ....

What's Putty's license? If license compatible we may be able to borrow 
its SSL code.

BSD or MIT... yes that is exactly what I proposed... it it VERY well 
coded and exceptionally small the whole putty app is in fact smaller 
than rebol.exe IIRC :-)


it has a LOT of goodies beyond a full SSH2 encryption set and EVERYTHING 
is stand-alone it relies on no external dll or libs.

even for things like zlib.

(gzip)

So, do we add https to the list? No matter if it gets adressed, it 
should be there imo. We somehow magically missed on that feature 
thru the whole development process. I never seen any blog, etc., 
which would even mention it ....

I think I might rename my nick to - "watchdog" :-)

yes https should be on the list... as a separate scheme, or a config 
of the http scheme as it was on R2

also server https would be nice - that one was not possible even 
with R2 https - I mean - you could not open open https://:443

Carl once admitted that is was possible but not "enabled".   AFAIK, 
he never told anyone the trick.  maybe its unstable and didn't want 
to put time on it.


theoretically, one could build an https server protocol in R2... 
the encryption algorithms are all there AFAIK in /pro licenses.  
its just knowing the handshaking protocols and all that... I look 
briefly at the RFC once and its not "obvious" to implement... at 
least not for the bg I have.

SSL is what you need. HTTPS would happen as a side effect.

but there is some of that built in to R2 already... which is why 
I say its *possible* to do in R2 as a server, the SSL code already 
in R2  would just have to be adapted to act as the server side of 
the handshake/transfer.

Wrong group: We need to add it to R3 :)

We need to add it to the priority list ;-)

Tasking is there already :-)

Just a question regarding GUI: We have GURUs like Henrik, Ashley, 
Cypre, Maxim. II have read that host source is being released to 
Maxim and Cypre. Why don't you build a GUI Team made of all those 
GUYs to push forward the developement ? I think they will make something 
explosive ! Also Gabriele has experiences because he build a prototype 
VID 3.4.

Our main goal would be to build the official GUI for R3, which Carl 
is forming from scratch. Right now it would be a bit foolish to go 
build our own UI to immediately go into competition with VID 3.4. 
It would be double work.

(I would still like to see Gabriele's MakeGOB dialect come to life. 
It can be very useful.)

Giuseppe - just don't worry :-) Look at the document Carl posted 
regarding host code release - there are several phases and Cyphre 
is definitely involved. I hope we cooperate for good ...