[General] Rhino+Batik Lively -and the bigger ria picture

[Peter Fraser]

1. Batik LK


 >>
>     We were, and still are quite interested in a pure Java version of 
> Lively.
> Actually, I got a big chunk of LK to work under Rhino+Batik at some 
> point and it even ran semi-decently on a fast machine. The major 
> missing bits were support for XmlHttpRequest and font metrics.
<<

thanks Krzysztof   -sounds like you were running Lively on Squiggle  
(the Batik example viewer) ,  and cunningly avoiding writing essentially 
the same thing in Java     -yes?


 >>
> It all used to run from the main source tree (Lively.svg is the entry 
> point). 
<<

where "main source tree" == 
http://livelykernel.sunlabs.com/legacy/0.8.5/ from out here in 
punter-land -yes?



> If it doesn't any more, it's probably a matter of few small fixes.
Squiggle in fact complains...

InterpExcept: org.apache.batik.script.InterpreterException: error 
instantiating
(0): class org.w3c.dom.xpath.XPathEvaluator is interface or abstract 
(Core.js#76
0)

I haven't looked into it, but its the sort of error I would anticipate 
making Lively run on another "browser" :-)


2. Bigger picture

>
> Of course, the Holy Grail of LK on Rhino+Batik would be to package it 
> as a Java applet that could broaden the reach of LK to those condemned 
> to IE.

inasmuch as living with the applet sandbox can be considered grail-ish  
-yes   -and that is what i had in mind by Rhino+Batik (as opposed to 
Squiggle, which i didn't know about)


> However, although both myself and my employer are emotionally attached 
> to the Java platform, the perception is that Java is not really a part 
> of the so called Open Web. From the Open Web perspective, the 
> Examotion plugin seems more palatable than Rhino+Batik, since it 
> appears to be a workaround for missing native support for a standard 
> graphics format, 

True  -but ironic how a closed source plugin for a closed source borwser 
is more "open web" than a 100% open source approach.

The IE plugin that I went looking for was in fact Firefox. There was a 
project to maintain a Firefox ActiveX control, but it looks dormant. It 
sounds as though such things will be easier on FF3 and perhaps the 
XULRunner project might yield something. I have nothing against the 
Examotion approach, and it seems the right thing to do (short of vml)    
-but the  browser inside a browser would be easy for you!  (and making 
LK in some sense a platform within a platform within a platform)


>
>
> As for VML, from what I've heard it was always noticeably slower than 
> browser SVG implementations (not speed demons, either), and I don't 
> think Microsoft cares about it much anymore, since they hope that 
> everyone will use Silverlight instead (much like Adobe, who stopped 
> bothering with their SVG plugin once they bought Macromedia and bet 
> the house on Flash/Flex). 

yes  -doing a VML LK would be a thankless task, but if it *could* be 
done, then there would be a native LK for IE  (although i suspect that 
vml isn't necessarily enabled or even enableable for many users). The 
work on the Examotion approach will of course make vml easier as you 
will have to deal with the JScript side


 >>and I don't think Microsoft cares about it much anymore<<

funny how people look at the glacial pace of IE development, and say 
"how can mozilla do more with less"  -they don't appreciate how hard MS 
is back-peddaling on html!


> Now, from what I understand, Silverlight supports (through XAML) a 
> graphics model quite similar to SVG, and it can run some version of 
> Javascript, and it runs on the Mac.
>     
> Lively/Silverlight, anyone :)?
>

as it happens i deleted a line from my post re java saying something 
like "would morhic over wpf/silverlight under dlr javascript be lively?  
-would it be Lively?"

i suspect you would lose live scripting under that model (whereas rhino 
is a pure interpreter right?  -so it doesn't hit the security 
restrictions that both java and .net impose around emitting bytecodes in 
the sandbox????)

but i agree, Silverlight sure looks **new and shiny** and a good LK 
target to me..


..on the other hand, if you think about Lively in the Silverlight, or 
Java (maybe even Flash)  worlds, perhaps you *don't* want the 
superstructure of a vml or xaml or flex

thought experiment:

at what point do you lose the spirit of the Lively Kernel?

a) A custom Lively applet which amounts to Squiggle (viz. Rhino+Batik)

b) As above, but with some mods to Batik to better support Lively (eg 
the color interface)

c)Further mods to Batik to implement the stripped down VML core required 
by LK  -ie the core that  Dan Ingalls mentioned on the FLOSS Weekly 
podcast (or was it somewhere else?)

d)Morhic implementation in Java or C#  -with a thinner, livelier Lively 
on top. 


hey, maybe you could implement morphic against awt in a constrained 
javascript style, that was translatable to java  -now where have i seen 
that sort of idea implemented??



regards
pete F