[General] King of Lively part II : LIE and CHEAT

[Dan Ingalls]

Peter Fraser <pfraser at spatialmedia.com>  wrote...

>IMO, the *Java* version of Lively is the fast route to a universal,
>fast, tight platform. Such a platform  is a prerequisite for an active
>community.
>
>Where has the Java work got to?

Peter, and all -

This is great.  This is just the kind of thinking we need to do now.

Just to let you know, this is exactly where our thinking was a year 
ago.  We got everything running on top of the JavaFX scene graph. 
This allowed us to run all the regular LK demos, but in addition Java 
(Swing) UI components in Lively windows (or not) and, hey, even a 
midi player to hook up to the PianoKeyboard.  It ran at about the 
same speed, though, because it was still all going through (our 
JavaScript emulation of) the DOM.  But Krzysztof also did a small 
experiment with direct calls on the graphics and demonstrated 
something like a 4x speedup -- I think we ran over 100 bouncing 
ellipses before slowing down to the normal speed for 25.  What a 
great strategy - runs everywhere on the Open Web, and runs much 
faster and ties into Enterprise libraries on the Sun platform.

Alas, this strategy competed with another strategy and our project 
got cancelled :-(

But it's 11 months later and people realize ours might have been good 
after all ;-)

Now to your topics...

>Rambling version: 
>
>Did I really say "Lively isn't ready for the prime time"?  I immediately
>regretted pushing send. It is close and beautiful, and packs more power
>into the browser than anything else  -but the prime time is unforgiving
>and insists that if you are going to play the browser game, you have to
>play it well. This means supporting four browsers on all the platforms
>those browser run on. Lively could do it, (though it's thankless task
>that never ends) but doesn't do four browsers now. And (yawn yawn) we
>need more speed, and can't rely on Moore's Law.
>
>So...
>To me, the way forward is obvious: Focus on the Java implementation,
>doing whatever it takes (meaning writing tactical Java) to make Lively
>as slick, responsive and consistent as it will be when browsers get
>their act together.
>
>I'm NOT talking about switching to Java. I'm talking about building, in
>Java, the kind of future-browser that Lively is anticipating. Lie and
>cheat unabashedly. If Rhino isn't performing (and let's not forget Da
>Vinci etc) then resort to Java. If (say) SVG doesn't offer a decent RGB
>interface, add it. If SVG is too slow, revert to Java graphics. Lie and
>cheat  -but be sure to have a browser implementation on hand lest you be
>caught.

I agree about this.  There are actually two ways to pull this off right now.
One is to take what Krzysztof did for the ellipses demo, and carry it
through to the full Morphic graphics layer.  The nice thing is that
(with a couple days' work ;-) the result could be wrapped up
as a Java Applet, and thus run in any browser where Java is available.
This would cover just about everything, including our current big
handicap, Internet Explorer.  This is the strategy I mentioned above ;-).

The other is to use the 2D canvas in O3D.  This is a very attractive
bundle since it includes not only a directly accessible canvas
library, but also the V8 JavaScript engine and full 3D if you want to
play around.

Of course these are both plugin solutions, but I think the LK story
remains clean as long as there is a full Open Web version that
remains reasonably compatible.

>If Lively in the browser works, great  -but let users know that Java
>will give them a better user experience today, especially for complex
>worlds, and serious Lively hacking. The Internet Explorer problem goes
>away(ish), and Sun research has a  (better than) ringside view of the
>java-ajax gap.
>
>[Aside: Silverlight would be an alternative to Java, but I'm assuming
>that Sun/Oracle remain involved and people continue to fret about their
>air supply. If Flash suddenly got a compliler on the client, it too
>would make a nice Lively incubator. ]

Yes, yes, and yes.  I think we're on the same page.

>More metaphors: I'm aware that the project worked with Java for a while
>but encountered too much intrinsic complexity. I propose that Java be
>considered *microcode*. The problem with the browser as computer, is
>that you can't microcode it. When you hit a wall, there are no options.
>Even Mozilla starts to feel like proprietary software.

Actually, complexity was not the problem.  It's just that we felt an
Open Web solution would get us much more traction.

>My sense would be to implement HTML Canvas in "jmicrocode" (if a
>implementation doesn't exist already). Canvas feels to me like a better
>lively substrate than SVG, and doing Canvas in Java (oops -jmicrocode)
>feels better to me than adapting to another graphics api (eg scene graph
>etc) in Lively JS directly.
>
>Tell me I'm wrong  (it's good for me).

You and Krazy Kat, huh?  ;-)

Well, the Canvas port does exist - check it out in Safari, FireFox or Chrome at
	http://research.sun.com/projects/lively/expt.xhtml
You can tell it's the real thing by evaluating
	WorldMorph.current().showDamageRectangles = true
and you will see good old JavaScript busily computing and refreshing
every damaged rectangle on the canvas.  [Of course it runs slower doing this]

So, the step to a Java applet or O3D is not that all hard to contemplate ;-)

	- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://livelykernel.sunlabs.com/pipermail/general/attachments/20091111/b1a92513/attachment.html