Hi Frank--
...especially if their sources MUST be closely connected with existing Smalltalk code, which does not run in the client like all the data-driven model definitions etc that I already have
There is no such requirement.
Of course, there is, actually it's an absolute necessity in my case.
Oh, I misunderstood you. I thought you were saying that such a coupling was a bad thing; I didn't realize it's a constraint you already have. Anyway, Caffeine is a distributed system. As long as your existing code can use WebSockets, you can use remote messaging between your code and the object memories running in web browsers. The Snowglobe remote UI examples, for example, have object memories running in the AWS cloud which can send messages to objects in a web browser, modifying that web browser's DOM objects.
...at the moment my UI is Mozilla's A-Frame 3D virtual reality framework, at 90 frames per second.
Well, what I have seen from the demos, the responsiveness to the cursor alone is so very far away from being acceptable...
That must have been the first Smalltalk Morphic demo, in which Morphic had full unoptimized control of the cursor. Since then, I've made UIs that use the Zebkit UI framework, morphic.js from the Snap project, A-Frame, and pure HTML/CSS. As it turns out, I now always use the web browser's built-in cursor handling for the normal case, even with Smalltalk Morphic, so one gets the native OS cursor handling speed.
...that I only believe, what you are writing, when I have seen a real-world JavaScript UI based on your system. Sorry, over the years, from bad experiences and one's own mistakes, I have become very skeptical and even more careful.
Sure, no worries; as older demos are replaced with newer ones this stuff will be obvious.
and it's impossible to port my >10.000 framwork and application classes to Squeak.
Caffeine can use Pharo, Squeak, or Cuis.
Well, my Smalltalk code is in neither of these and it would cost many months of work and the loss of very essential tools to port this to any of your supported systems.
Oh, since you're not using Pharo, if were were to continue this conversation it should be off-list in private email. Anyway, you could use Caffeine's remote UI server component in your Smalltalk environment, and just use web browsers for the UI. I'm currently adapting the remote messaging parts to all the other Smalltalks.
However, *I see one advantage in your approach*, assuming that no Smalltalk source code must be sent to the client (I have no info about that) and this is in the fact that Smalltalk byte code is, of course, a much better protection of IPR than any obfuscated JavaScript could ever offer. But the price for this advantage would be far to high, as far as I can currently tell.
No, no Smalltalk code need be sent to the client, although you always have the option of sending remote messages. thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)