[General] Rhino+Batik Lively -and the bigger ria picture
pfraser at spatialmedia.com
Fri Jul 18 20:29:18 CEST 2008
1. Batik LK
> We were, and still are quite interested in a pure Java version of
> 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
where "main source tree" ==
http://livelykernel.sunlabs.com/legacy/0.8.5/ from out here in
> 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
(0): class org.w3c.dom.xpath.XPathEvaluator is interface or abstract
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
> Lively/Silverlight, anyone :)?
as it happens i deleted a line from my post re java saying something
-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
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
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
hey, maybe you could implement morphic against awt in a constrained
that sort of idea implemented??
More information about the lively-kernel