World: r3wp

If by "like a browser" you mean implement HTML rendering and styling, 
a JavaScript interpreter and all of that, then I agree. If you want 
to implement a REBOL browser, then you are dead wrong. It's not the 
browser part that is the hard part.

I meant the former

I don't see the point to the former.

If the html browser part is seperate from the rebol "bowser" (as 
a plug-in using web kit?) it would not be too tuff.

That is also not what Carl is doing.

I don't see the part to implementing an HTML browser at all - we 
already have those, and they suck.

part -> point

I can see the point to implementing a compiler from a REBOL dialect 
to HTML/CSS/JavaScript though.

html borwser would allow rebol to infiltrate the masses...No one 
will use rebol only browser if they can't also access google or any 
of their other favorite sites. A An html plug-in could activate when 
an html page is requesteed...?

No, an HTML browser would not allow REBOL to infiltrate the masses 
because they already have HTML browsers and most of them don't want 
to switch. I can see the point to making something that works in 
the browser that they already have, but not one that would require 
them to switch browsers because that would fail.

They would switch for the added benifits rebol pages would provide 
but they would still be able to accesshtml until those sites cought 
up to speed...

It would be better to work with their existing browser because they 
won't switch. I may not even like Firefox but I can't switch.

It needs some good apps that force people to use it. Onec they know 
they can use it alos for html why would they open two browsers if 
one does can handle both types of web content.

No, if we are going to force them to use something other than HTML/CSS/JavaScript/Flash/Silverlight? 
it would either have to work in their existing browser, or be something 
seperate that just gets installed with an app they already want, 
as a side effect.

Personally, I don't want HTML browser overhead in my REBOL browser.

The latter...exactly.

I'm building an app that works great as a standalone app but I can 
see it working in this "browser" thing as the rebol "browser" I believe 
will be proving a framework to extend my app..things like caht, file 
sharing, and other things not yet thought of. If i I have a base 
of users and I stear them to use the browser as it will provide additional 
benifits to my app..that's a bunch of people nows using it that will 
quickly discover they can also rech the html web. Why us ie or firefox?

proving>providing

For that matter, unless you support their existing web services that 
they already have their data or the data they already want in it, 
it won't matter. That means their existing webmail account and Flash 
video. If you can't play YouTube (and RedTube, ...) it won't matter.


People don't care about the underlying technology unless they are 
techs. If you make a REBOL browser so that you can do REBOL stuff, 
and then try to support the old web stuff thinking that people will 
try the REBOL stuff and find it to be better, you will be wrong. 
Most people won't be able to tell the difference, because it isn't 
the technology that matters, it is the content. If you have the best 
content available in the most convenient way, people will install 
your software to get at it, whatever your software is written in.

The real advantage to the REBOL browser isn't web integration, it 
is taking the real advantages of the web (aside from installed base) 
and applying those to REBOL, but better because we don't have that 
legacy markup crap.

Agreed

agree again

We are not going to compete with Flash directly, not unless we can 
provide a better source of free videos of cats running on treadmills 
than Youtube. The only company that can kill Flash/Silverlight video 
is Google, because they can add HTML 5 video to every open source 
browser and switch Youtube to use it. Nothing that the REBOL community 
can do will work on that scale.

It is thus better for us to do something that Flash can't do, rather 
than to try to beat Flash at its own game (like Silverlight).

Agree here also, I want cross platform GUI where the rebol browser 
provides UI and other services to applications not just content. 
 The value in the Google applications is not their quality (which 
is okay) but in the access from anywhere feature.  The HTML/Browser 
is trying to grow into the application space but is really at a disadvantage 
because of the technology.

Links, discovery via search, anywhere access these are good things 
that can also be done with the networking strength of REBOL, no need 
to saddle that with HTML/CSS and the whole mess of patchwork technologies 
layered on top.

anything we can build in rebol can be built with another technology

Rebol is a niche product, and unless it reaches critical mass (of 
developers) will probably remain that way.

That said, I've been discussing a new project that will probably 
use Rebol

Critical mass is a challenge for sure.  I've been bouncing around 
all the "popular" technologies for some time while earning my keep 
with old fashioned database applications.  Some are very interesting 
and have good strengths, none are making creating solutions easier 
or even better in most cases.

I'm not sold reaching critical mass is what we should be chasing 
just yet.

The concepts behind Rebol are too left field for critical mass. Genius 
is not always appreciated.

Everything is a niche product, even Flash. There is no general purpose 
product. Find your niche and go for it.

For me, critical mass is being able to use REBOL for work and my 
research and not have it be career ending. I'm there already :)

I don't care about any mass

I just want it to work well enough for me to develop applications. 
 Who cares what they're written in?

Well, as you have to write the applications, I suppose you would 
care. Not your users though :)

yes, that's assumed :)

For me the neat thing is that I can give my users access to Rebol 
inside the product and so they can extend the product as they wish.

One language for all ....

Hey, I had an idea today that you might be interested in. I want 
to come up with a REBOL notation that has the same basic semantics 
as JavaScript but is still valid REBOL syntax. Corresponding concepts 
should match corresponding syntax (= to :, etc.). If it could be 
executable by the standard REBOL interpreter that would be even better. 
As far as I can tell, the only thing without an approximate mapping 
is regex.

Obviously this dialect wouldn't be as powerful as the DO dialect, 
but if it is a proper subset it could be executed by DO and its buddies 
as is. Once you have this, all you would need is a syntax transliterator 
and you would have a JavaScript interpreter in REBOL.

you mean a javascript dialect for Rebol ?

Yup.

Go Brian go!

I was thinking that if I could do that, then reimplement the rest 
of REBOL in that dialect, I could write a REBOL compiler to JavaScript. 
At the very least I could write a JavaScript compiler to REBOL. Or 
for that matter, a compiler for a subset of REBOL to JavaScript. 
Semantic equivalency is what would matter here, not syntax. Syntax 
is irrelevant.

Having a javascript interpreter embedded inside Rebol would allow 
more users ( familiar with javascript ) to write their own add ons 
without having to learn Rebol.

Agreed.

It would also bringe the gap of REBOL and....the "web". :)

Should I make a task for this? :)

Is this on 20% time? :)