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

[Peter Fraser]

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)