World: r3wp

In this example, the REBOL developers would be Shakespeare, and the 
Intel chip developers (PHP programmers, etc) would be monkeys.  :)

no, web developers are monkeys. Fork tries to say, that simply put, 
you can't avoid the trends.

One aspect of the new "reality" is that your computer always has 
a web browser running, it has to.  So any comparison of REBOL and 
a web browser you have to do is to run REBOL * in addition to* the 
browser.  Not fair, just true.  Performance-wise, how quickly the 
app starts up or not doesn't matter anymore... you've paid the startup 
cost for Firefox (or whatever), you've got the code pages in, they're 
there you have to live with it.

pekr, you mean in the browser? I hate that argument because I'm contantly 
intalling active -x or new flask plug-in etc. It does not keep me 
or the majority of users from dusing these sites.

stear=stare

In terms of view as part of the core: Some plans down the road (Wildman) 
may require cusrtom answers. Also when you want to be on cell ph0ones 
or pda's you might not want to attach large libraries to your app. 
I do not know the size of these gui libs but they can't be as small 
as vid.

so, simply put - forget View - that is for us, long time rebollers, 
this is our toy. Now let's integrate core into browser and use such 
bindings, like others do ...

Pekr: Yes, basically what I suggest.  :)  But you need not abandon 
view's dialect... or at least, not the idea that what people see 
in a browser is the result of dialect-based code.

Noone said View is going to be part of the core! I would like to 
send you to R3 architecture page: http://www.rebol.com/rebol3/architecture.html
, and as you can see, all RT is responsible for, is platform agnostic 
rebol.dll or rebol.so, which you can statically or dynamically link 
even to something like Delphi.

Fork - but VID3 is so well abstracted, separating methods of user 
input, widgets update, that no clumsy XML forms reach its knees, 
so we will see ...

My preferred way will be R3 browser plugin. Because ppl accept small 
installs, if deployed well ... and "well" means browser here :-)

Yes, well, the main download includes it... and starts up with it... 
I just mean to say that whatever it is that's the small download 
off the site that new users are encouraged to grab and comes with 
standard features would fire up a browser... e.g. even the console

e.g. look at this

http://tryruby.hobix.com/

Simply put, what I say for few years - web browser is not browser 
anymore. It is a "container" for various technologies, and it will 
become central point of app development in the future.

Very, very, cool.

And already showing off a lot of stuff the rebol console *isn't* 
doing.  The browser is the platform, windows API + Xwindows API + 
Carbon/Cocoa are headed out... http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

Anyway, just wanted to put forward these ideas.  I am looking at 
what Qtask has done and getting a grasp on their methods... was just 
wondering if there was any push to make those methods more mainstream 
as a replacement for REBOL/View in the standard download.

what isn't rebol console doing? You have to be kidding, no? Our console 
can be even used in full screen, navigating ...

Well, watching what you type and suggesting things you might try 
in pretty out-of-band places, being the most prominent aspect.  :)

If they wanted to, they could make that console take up the whole 
screen, and put a button there to let you do so.  The browser would 
allow it.

but that is surely not Ruby console, right? :-)

I'm just talking about leverage...

So you never probably tried rebol reflectivity and self inspection? 
:-

leverage .... Bzzz ... loading vocabulary :-)

The language is not the point, really, just the point that if new 
users downloaded REBOL and got something like that instead of a REBOL/View 
window, they'd say "oh, snap!"  :)

btw - some old nice stuff for you - times when Jeff Kreiss etc. were 
part of RT ... http://rebolforces.com/

so what do you prefer? Getting rebol console not knowing what to 
do, or getting simple console with "Type desktop to start the Viewtop." 
and visiting visual world with plenty of examples and demos to run?

But I do agree that having that directly in browser is kinda cool.

Well, I understand your position well, I just try to defend REBOL's 
position. We are trying to get things right for R3, we are just not 
yet there ...

Well, point being, I don't have a whole lot of use for REBOL/View 
because I don't care for native apps.  And as far as I'm concerned, 
REBOL could drop windows and mac support for REBOL/View and just 
run in a virtual linux machine with a lightweight X-windows.  I'm 
a big believer in VMs.

(and letting those VMs do the work, rather than port: http://hostilefork.com/2007/11/03/virtualization-and-the-integrated-circuit/
)

(Nice thing about making your "one version" linux is that then people 
can download pre-configured VMs with the software installed and not 
worry about licensing of windows or os/x )

In any case, thanks for listening... again, I'm just trying to understand 
the direction.  It sounds like you're suggesting a distribution of 
REBOL could be made which did not include bind to the host's native 
GUI but targeted the browser/server/UI and had dialects for that.

Maybe REBOL/view's dialect or a subset could be used for that, even...

I do appreciate there are applications that don't belong in a browser 
at this point (e.g. World of Warcraft, some 3D modeling, etc.) it's 
just that REBOL seems more like a text processing / messaging language...

But AltME does seem like it's playing catch up to the likes of Meebo 
http://www.meebo.com/meebo/

I'll look at cheyenne... TTYL

catch-up to Meebo? Only hardly. Are they secure? :-) Lot's of spam 
there, just basic toolkit awailable. Typical ajax rich-app wannabe.

Well, I just wanted to give a non-Qtask example.  I don't know how 
secure AltME fundamentally is compared to, say,  Gmail.

I guess time will tell, but my only point is that if the effort had 
gone into a web-interface-compatible view dialect instead of targeting 
native then REBOL might be quite popular today, it would also be 
easier to deal with things like UNICODE in the interface...

PHP is a nightmare and got popular because they made it easy to write 
web apps.  Er, at least easy to get started with a hello world web 
app, and people pushed forward from there.

Gmail is not https?

there will be some attempts into generating 1:1 html VID interface 
me thinks :-)

http://mail.google.com/support/bin/answer.py?hl=en&answer=8155

Is that secure enough to compete with AltME's security?

If I got some Finnish hackers and gave them a task to hack into my 
gmail account vs. my AltME account by watching my wireless network 
traffic, would you bet $10,000 that they'd hack Gmail first?  :)

I don't know whether it's right or wrong, I just know that people 
aren't investing in GUI dev anymore for conventional "forms based" 
apps unless the form engine is a browser. Speaking broadly, here.

I am no security expert, but how they can easily hack https? Or is 
that an irony? AltME should, in theory, be secure :-)

I'm no security expert either, that's why I was asking!  But I guess 
I am just saying that native programs don't seem to be to me in the 
long run a security benefit over a web-based one... thus I'd take 
security out of the argument for why REBOL/View would be better than 
REBOL/WebView.  It could be made to use https out of the box, I guess..