Where Rev could be going...

[Bernard Devlin]

 >>
creating a Rev plug-in (particularly one that has all the
behaviors we expect) is almost impossible. Revolution does not map well
to web servers
<<

Jacque,

I don't really understand this, either in the context of a browser  
plug-in to display Rev content "as is", or in the context of  
generating a Flash/Ajax app from a Rev app.  I mean, I don't see that  
the Flash timeline paradigm maps to web servers but the Flash plug-in  
still provides a fairly compelling web application delivery mechanism  
for some people.   Laszlo uses Java to generate their Flash apps (and  
presumably to generate the Ajax version of the same app).  There is  
arguably a much greater mis-mapping between Java and Flash/ 
Actionscript or DHTML/Javascript, than is the case with Rev.  
Obviously on a syntactic level Java and Javascript have more in  
common than Transcript and Javascript, but Java's text manipulation  
capabilities are much more cumbersome than those of Transcript.

I think that a stronger case can be made to say that browsers don't  
map well to web applications.  Browsers were designed for static  
content, and there are amazing engineering efforts underway through  
just to make web applications behave more like fat client apps (and  
they are still quite a way off working consistently).  After spending  
the last few years building web applications for browsers, I decided  
to finally reverse the effort and use Rev as my presentation tier for  
web applications.

I think you are referring to Andre's reply to me on 4th November  
("Re: How Else to Interact with Browser (was Re Revolution	Web  
Browser Plugin)").  With all due respect to Andre, I think he is  
confusing two different solutions (a browser plug-in to display a Rev  
application as an "applet" vs. the transformation of a Rev app into  
an Ajax/Flash app).  I understand that the latter is difficult, but I  
don't believe it is impossible (or else Laszlo or Morfik could not do  
it).  But the former in principle should not be that difficult -  
there are loads of browser plug-ins available, and I would say it is  
precisely when there is a mis-mapping between an environment's native  
programming/design/content paradigm and that of the web that a plug- 
in is most useful.  That's why we see things like VRML, 3D, etc plug- 
ins.  However great we might believe the mis-mapping is between Rev  
and the web, it is surely a closer mapping than that between a static  
page of text and a dynamic, explorable 3-D model.

As I pointed out in reply to Andre: the Squeak people have produced  
browser plug-in where an entire SmallTalk image (= a GUI/ SmallTalk  
VM runs inside a web browser), and the messaging paradigm is probably  
stronger in SmallTalk than it is in Rev.  I think the whole point of  
a browser plug-in is that (once a plug-in is downloaded, installed  
and properly configured) the browser window (mostly) just serves as a  
frame for what is a locally installed application.  A few years ago  
when there was so little interest by Runrev in building such a plug- 
in, I even looked into doing it myself (and I'm no C programmer).   
There are, I believe, clearly defined ways in which the plug-in must  
interface with the browser.  What I found was the major stumbling  
block was the lack of information about how to build the plug-in -  
most of the books that detailed how to do it were out of print,  
because the 'time of the plugin' was sometime in the mid to late  
1990s.  If I had been able to get hold of that information, I would  
certainly have tried to do it.


Bernard