World: r3wp

I'm a little concerned about the direction to take Desktop Library 
II.  I want to make Sunanda and the team happy, but I don't really 
want a product with a pre-expired shelf life.  It's getting close 
to 3/4s complete, but have a feeling it may be an R2 only code base. 
 :(

Henrik - what does it mean, later? I am for later release, if you 
say its vital ... just state it a bit bettern than 1.8. I would be 
fine with 1.9., or 1.10. if you ask me ....

In which case, R2 will get a stable release of ESMTP and LNS (he 
said with his fingers crossed)?

Brian - so you still think that R2 release is going to happen? Well, 
maybe it will, but so far my opinion lasts - there will be no R2 
release - there is no time for it, and it steals time from R3 issues, 
and R3 is next-gen for us. My suggestion is to concentrate upon R3 
already.

pekr, I'm just saying that the developers don't need to answer questions 
for things that are already planned. "what about this?" "what about 
that?" "why is X feature not there?", etc. Rather spend time finishing 
VID3 than talk about how to finish VID3. :-)

also - one of motivations for R3 was that LNS needed better networking 
model. So not sure r3 LNS release could be so easily backported to 
r2?

Henrik - you know me and you know what I fear - pekr coming to final 
r3 VID, playing with it for few minutes, asking - how would I do 
that? And getting the answer, that it was not inteded to do such 
a thing and that it would require VID rewriting :-))

Yeah, but a production release of R3 is what, 18 months away?

so much away?

imo release could be regarded production level, if features added 
are stable. And that is imo also the plan. e.g. iirc unicode will 
not be there for 3.0 ... it will come later. But that does not mean 
3.0 could not be used for many usefull things already, and being 
called a production release, no?

I don't think it's that far away. I think there will be a ton of 
additional work on extending R3, that could easily take 1-2 years 
after the first release of R3.

That's what I was thinking.  R3 won't really be mainstream for quite 
a while no?

everything takes its time :-) I'm just of the opinion that soon, 
an army of developers will be needed to take advantage of R3 to bring 
it to its full potential.

But what about the "user" community during that phase.  They won't 
wait around will they?  Not to say I don't plan on trying my best 
to help out with R3, but I don't see taking it to a construction 
site boss for quite few more days/weeks/months.

easily everyone in here could contribute to official parts of R3, 
given that the quality of work is good enough. :-)

we need new C coders ... it will be a tough task, to attract new 
ppl being able to contribute good C code to extend REBOL ...

brian, I'd start adapting simple scripts from R2 to R3. Do that by 
adding multithreading, adapting to async HTTP, etc.

pekr, driver developers will be essential.

So I'm still back to planning for say an Invoicing application for 
a site boss.  That will be R2 code base for quite some time, no?

Cheyenne, RebGUI, Rugby et al...it's kind of where I live right now.

brian, depends on the state of VID3, I suppose. Just right now, you 
can only build simple apps with it. I don't know the state of the 
networking. Actually I haven't work with networking at all in R3. 
:-)

well, if you are totally depending on those, you should probably 
stick to R2 for now and try out R3 for simpler scripts and wait for 
similar solutions to be ported to R3.

Henrik - re VID - currently simple apps, because of incomplete style-set, 
no? But foundation is stronger than VID2, isn't it?

Ok, so there has to be a plan to keep mainstream app building with 
forward momentum while building up R3.  imho.  So doesn't that mean 
wrapping at least a production release of 2.7.6?

pekr, yep, incomplete style set. a few issues to be worked out with 
the layout model, bugs here and there and optimization.

brian, I think 2.7.6 is a good idea. It currently requires that someone 
clones Carl, so he can finish 2.7.6. :-)

Part of my involvement over the last few months has been rebol.org, 
and I plan on being one of the grunts getting it R3 ready, but consulting 
work will still need to be a viable option for rebols until R3 can 
be taken to say an Insurance Company or small business, no?  Or is 
R3 going to hit the ground running so fast that it can be taken to 
an Executive sooner than later?

driver developers will be essential.
Why? I thought, REBOL had a minimum interaction with host OS.

Geomol, OpenGL, DirectX.... maybe? :-)

Skip DirectX, use OpenGL and implement it using GLUT. It works the 
same on all platforms.

No I think that RT will try and have a minimal interaction with host 
OS...that's what I took from the DevCon talks.

btiffin - I would not depreciate r3. Remember - when r2 came, it 
was better than r1 even in beta state. It will not probably happen 
with r3, but otoh r3 provides you with many more capabilities, e.g. 
threading ....

I can live without 2D hardware acceleration, I guess. But if there 
is a standard way of having it across platforms, it could be a good 
idea.

Geomol, that's the beauty of R3: We don't have to skip DirectX, since 
a developer can make that interface if he/she wants to.

Geomol - I jus hope rebcode is there, with refinements guys outlined 
... it should help too ...

Geomol, but I agree for the first round, OpenGL is more important.

I'm all for porting, but not if wating for key features means delaying 
work for "normal" folk.  I'm at a point where some of the bosses 
are actually getting pretty good at R2 data types.  :)

And I'm just starting to get people here involved with GNU/Linux...so 
I'm banking on that R3 release not being too far behind.  :)

Pekr;  Re r1 to r2.  I was a dropout from the computer biz from 1999 
till about January this year, so I was watching from a purely curiosity 
perspective, no vested interest.  Now the interest is much higher 
and far more vested.  :)  In that regard I'm still new.

Henrik, it's good, that R3 is open in a way, that it's possible to 
interface all kinds of systems. But I wouldn't recommend interface 
too deep into anything, that is tied to a certain platform, like 
DirectX is. We should find good cross-platform standards and interface 
with those from REBOL, so all REBOL software can run on anything.

Geomol - each coin has its two sides. Maybe there are some Windows 
only developers. From their POV, there is simply DirectX available 
on each PC, so no special need to install one. In the case of GLUT, 
they will have to either install it separately (I don't know anything 
about it, so maybe it is just few libraries), or simply pack with 
their app ...

Afaik, OpenGL is on Windows. I'm not sure, if GLUT is or it is linked 
with app.

My point is, it's good that REBOL is open for interfaces. I just 
wouldn't recommend interfacing with DirectX. That's it.

Like I wouldn't recommend interfacing with e.g. the Velocity Engine 
on Macs, because it's tied to Mac OS and the Altivec technology found 
in G4 and G5 processors.
REBOL is about cross-platform also. Write-once-run-everywhere.

OTOH - why not to optimise to what is native on all platforms? Under 
the hood, so that the programmer does not need to care? Well, app 
performance would probably vary between the platforms, but ....

Geomol, I think you mean that _RT_ should not focus on DirectX. :-) 
I don't see anything wrong with a 3rd party developer doing work 
on interfacing DirectX.

I would like to first see new View with rich-text, VID, ability to 
embed externall windows (e.g. video player, etc.), decent sound, 
really good VID, tools like screen painter, debugger, cross platform 
rebgui to give initial boost to apps, and then further fine-tuning 
using DirectX or View plug-ins (access to buffers etc.)

Yeah, something like that. If you interface to something special 
found only on one certain platform, your software will only run there. 
If you support many such technologies on many different platforms, 
you end up having huge problems supporting new versions. Trick is 
to find the right things to interface with. Carefull selection! But 
of cource some specialized developer can interface with such things 
for some special software only to be run on that single platform.

cross platform rebcode
 in my above text ...

Yes, rebcode everywhere solve many performance issues! I agree!