[General] Is anyone working on Rhino+Batik Lively?

The backspace issue highlights the sheer heroism of those making Lively
run on browsers :-)

As a matter of pragmatism   -is anyone working on the Rhino+ Batik
implementation? I note rhino-compat.js in the source download.

I'm negotiating a research project where it would be great to use LK,
but I don't want to be researching heroic backspace workarounds on windows.

On the other hand, a JRE requirement  would be workable (especially
given the demonstrable path towards "nothin-but-browser" ) .

Perhaps I'm being naive about the difficulty of the Java approach, but
it strikes me as being a great complement to pure browser Lively  
-having different deployment, hackability and performance tradeoffs.
I'm not personally up for a complete Java LK implementation, but if
there was half an implementation sitting somewhere, I'd be keen to have
a look.

I would also be fascinated to hear any comments on the relative merits
of the Java approach vs Examotion(etc)  -as an IE solution   (and come
to that, on the viability of Lively on VML)


pete F


I really meant to do some more research before asking these questions,
but well   -I get excited.

Hi Peter,
        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@some  
point and it even ran semi-decently on a fast machine. The major  
missing bits were support for XmlHttpRequest and font metrics. As a  
stopgap measure, I simply made up the font metrics, so text looked  
ridiculous, but it did show on the screen. As for XHR, we've been told  
that there is@least one implementation out in the wild that could  
be potentially integrated with the codebase.

I was planning to try to access font metrics from Javascript using  
Rhino's Java interface, but never got to do it, if you or anyone else  
were interested in taking a look, that would be awesome! :) And I'll  
be glad to pass on whatever little I know about the problems.
It all used to run from the main source tree (Lively.svg is the entry  
point). If it doesn't any more, it's probably a matter of few small  
fixes.

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.  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, as opposed to an independent platform  
and execution engine (actually two, JVM and then Rhino on top of it,  
in addition to the browser's JS engine). It's probably also a smaller  
download... On the other hand, it'd be nice to have access to all the  
goodies that come with the Java 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). 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 :)?

        Krzysztof


On Jul 16, 2008,@4:11 PM, Peter Fraser wrote:

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@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@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