Short version: 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? 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. 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. ] 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. 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). Pete F (gerbil) _______________________________________________ General mailing list [email protected] http://livelykernel.sunlabs.com/mailman/listinfo/general
