How Else to Interact with Browser (was Re: Revolution Web Browser Plugin)

Bernard Devlin revolution at knowledgeworks.plus.com
Fri Nov 3 21:57:07 EST 2006


Andre,

I really appreciate you writing such a long and thoughtful reply to  
this. Especially since you are in Malta, and English is not your  
first language.  You really are an amazing individual (and thankfully  
quite indomitable).

The issues you bring up are very pertinent.  However (and Dan will  
likely chirp in here), I don't see how the message path in Rev can be  
that different from the way that messages pass in Squeak.  The Squeak  
plug-in is a full Squeak/Smalltalk VM, so any message events that  
arise in interacting with the client/ UI are also passing through the  
rest of the Squeak VM.  If those messages (e.g. URL connections) are  
not resolved locally, then they must make network connections in  
order to get a response.  I don't see how this is any different with  
the Rev VM/engine.  I think what you might be imagining is a Rev  
browser plugin that is intimately connected to a Rev server  app, and  
you are envisioning the messages passing in a message path between  
client and server.

I personally think that with the developments in AJAX (as much as you  
might shudder at that acronym, even Alex Russell - the NetWindows/ 
DoJo guru also hated it and railed against it), and the developments  
with Flex, and with Adobe Apollo, the time for a Rev plugin has  
actually passed.  I requested years ago that Runrev produce a plugin  
and a mechanism to decompose stacks to XML and then recompose them.   
I've recently begun on such an exercise myself, and am currently  
working on stacks that are dynamically configurable from XML  
specifications.   For my projects it is no longer important if there  
is a browser plugin - my Rev apps (in terms of layout and workflow)  
are going to be vended as XML and consumed and presented by a Rev  
app.  As far as I'm concerned, the AJAX widgets are still very  
primitive.  I understand how the business model of RunRev relies on   
the scriptlimits and the purchase of the IDE, and I have no  
complaints about that.

So I fully appreciate the limitations of AJAX and the additional load  
it can place server-side.  Suffice it to say, in the current  
application I'm working on it is not the Rev side that leaves much  
room for speed improvements - client-side I can sort a 10,000 row  
table field in 10 ms, but the middleware server is taking 1-3 secs to  
select and return those 10,000 rows.

None of us are really clear what Adobe's Apollo offers, but it  
certainly seems to be offering to close the gap between Flex and Rev,  
and I sincerely hope that RunRev are watching it closely, because it  
could well marginalise Revolution.  I'm building my applications such  
that I will be able to switch between Rev, Flex, Laszlo or Apollo as  
a delivery mechanism.

Regards,

Bernard

BTW... a friend of mine visited Rio, and one of the highspots for him  
was his visit to Niteroi and seeing the Niemeyer museum (the photos  
are enough to make me want to visit Rio too).



More information about the use-livecode mailing list