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).
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
