Peter Fraser <[email protected]> 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
_______________________________________________
General mailing list
[email protected]
http://livelykernel.sunlabs.com/mailman/listinfo/general
