craig at blackpagedigital.com
Tue Aug 15 18:47:57 EDT 2017
> > > ...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
> 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
> 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
> 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.
Black Page Digital
Amsterdam :: San Francisco
craig at blackpagedigital.com
voice through 2017-09-12:
+ 1 510 833 5799 (SMS ok)
+31 20 893 2796 (no SMS)
More information about the Pharo-dev