World: r3wp

Anyway, I would to see V3 create windows that can scroll easily with 
text and graphics as browser  windows do

FF is extremely bad at multi-threading. Unix philosophy: MT is bad

a browser container for IE or whatever would be very nice

Yes, FF's Gecko engine is unwieldy and they're currently decreasing 
portability. WebKit is much easier to embed

How's R3's rich text facilities ?

Where's our Deep Throat when we need him??

Graham;  It's Cypher code so ... wow is how.  Impressive use of REBOL 
dialecting imho.

The need to render simple HTML & PDF within the app is the reason 
I have not used R2 on internal projects. I've had to move on to web 
apps and I'm using more Python now than Rebol. The screenshot on 
Henrik's blog is very, very good! Web apps, for good or bad, are 
here and now and "rich" web app frameworks  are  actively being developed. 
Rebol faces a lot of competition in this area. The R3  potential 
is amazing and whilst I have my own priorites for new features, I 
look forward to trying out the beta when it's released. Can I just 
say thanks to all of the developers for their hard work so far.

Perhaps we need a list of deal breakers like this?

Printing has always been a major problem

But since it has been a platform specific problem - it has never 
been addressed

Yes, I already named it - the most tough part is - how to seamlessly 
integrate. We will need JAVA or .Net integration sooner than later. 
Reading reboltalk.com discussions, I can see, that Gabriele does 
kind of bad job there, claiming that having REBOL for .Net contradict 
REBOL purpose. I can't agree ...

If rebol is going to be a dll .. won't that help there?

Other integration is web technologies - there are here to stay .... 
I don't think we will be successfull in creating html, css output 
it rebol. Do we want to write web-browser in rebol? OTOH, even Python, 
using e.g. VxWidgets, has rather simple html support widget, not 
full browser support. So, DaveC, what kind of html integration in 
Python are you talking about?

And if we need full html support, well then, I suggest khtml webkit, 
as Mozilla is known of being difficult to wrap (unless situation 
changed from two years ago. They are supposed to have minimo or something 
like that for mobile devices)

rebol as .dll or even static lib will help much. You will be able 
to integrate e.g. to Delphi, call rebol from your other app. But 
- does JAVA use dlls? Does net use dlls? I don't know, but I doubt.

Having REBOL in JAVA would get rebol onto most mobile devices and 
nearly everywhere. OTOH - JAVA on mobile devices is restricted, not 
consistent across the platforms - just ask Cyphre for his experience. 
So, maybe, and I repeat - maybe - it will be easier to port REBOL 
to most platforms, rather than to do REBOL-in-JAVA project.

Other thing is - how you get REBOL onto cell phone? There is JAVA 
there. You are not allowed to upload other kind of apps.

Here's an example of integration - http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython
- you simply get whole .Net infrastructure available to Python.

But we have to decide on priorities. As for me, I prefer finished 
R3 with plug-ins, and then web browser plugin. I think we can break-thru 
with REBOL itself. Those kind of integrations can come later.

My main interest is in building stand alone applications so I have 
less requirement for .net and java

Is use by fortune 500 companies important?   Is this needed to validate 
Rebol's existence?

I suspect not .. if the language is cool enough, hackers will use 
it .. and it will then eventually find its way there

I think REBOL should work with COBOL, and should be ported to mainframes 
;)

Of course it depends on how RT plan to derive their income

Is it from consulting with R3?  Or from building applications in 
R3??

frankly the sdk should be free

The Java Native Interface can be used for calling native code libraries

putting barriers to use in an already very small developer base is 
counter productive

I hope R3 has no barriers ...

I mean after one buys a couple of sdks and /pro versions .. there's 
no real need to purchase any more.

It's a dead end as a source of revenue unless you have lots of new 
users

the first encap licensing scheme was very unusual

Pekr, tell us more about R3

will we be able to build networked games with 1000s of concurrent 
users ?  :)

Dunno :-) But - why not. Surely View is not the right engine to create 
games ;-)

I mean - supporting infrastructure - networking - why not ...

Gabriele wasn't able to get chord working

in R2

shouldn't be a problem in R3.

what about memory management?

is it better?  I used to get out of memory errors in encapped apps 
if I waited long enough ... days to weeks

Support for 64 bit windows?

can't tell yet. no tests that big have been run yet. there are a 
few recycle bugs that are being fixed.

my Cerebrus antispam program would eventually die from lack of memory 
... after some weeks of running

I would like to resurrect it if I can .. if memory management has 
improved.

the decompress function has a memory limit option. it's been discussed 
whether it should be removed or not, but such things will be necessary 
in an embedded environment.

overall R3 uses less memory than R2

do you know why?

More optimized datatypes, tighter code and GOBs.