XSmiles, Batik, and BSF

[Jason Foster <ja...@uwaterloo.ca>]

I've been lurking on both of these mailing lists for a little while, as 
well as some of the SVG lists, and would like to make a suggestion to both 
development teams.  In the immediate future I can't offer more than the 
suggestion and discussion, but if things go well I might be able to offer 
some warm (student) bodies.

The possibilities afforded by a combination of SVG and XForms is starting 
to gain some traction.  The SVG community is investing *way* too much time 
putting together interface widgets that accomplish much less than XForms 
(except maybe for tree controls).  There is currently no easy way to 
emulate, in a cross platform manner, the simple XSmiles demo of a 
searchable map (using SVG and a text edit control).  Unfortunately the 
XSmiles team is currently not using the Batik framework.

The good news is that according to Mikko Honkala the XSmiles team has 
moving to Batik on their TODO list.  The bad news is that according to Juha 
Vierinen there are currently a few major stumbling blocks:

> The scripting is one issue (we have our own, and they have their own). I 
> guess that this could be solved by letting the two scripting scemes 
> co-exist. Another issue is the SVGDOM implementation. It would be nice to 
> have only one DOM tree for the rendered document. Otherwise we would have 
> to keep two different trees in memory, and keep them synchronized.

I can't speak to the DOM issues, but I would like to suggest that both 
teams adopt the BSF as their scripting implementation.  Once both teams has 
transitioned to the BSF, merging the scripting support should be (knock on 
wood) straightforward.

Based on a recent post to the BSF mailing list, I know that the XSmiles 
team is aware of the project.  According to a search of the batik-dev 
archives, BSF integration was being discussed a year ago, but has never 
materialized.  Given that both projects have looked at BSF, and neither 
project has dismissed it as being inappropriate, it looks like a possible 
winner.

Moving both projects to BSF offers a number of advantages.  Foremost among 
these is interoperability.  An embedded Batik would benefit from being able 
to hook seamlessly into the scripting support of its host (say, XSmiles).  
BSF support also offers the advantage of not having to worry about updates 
to the Rhino and Jython packages.  A final thing that BSF offers, although 
not necessarily a practical one, is the ability to script SVG using Ruby, 
which would just be cool :)

The primary disadvantage of BSF that I can see, beyond having to replace 
the plumbing, is that Batik seems to have done some heavy customizing of 
the Rhino interpreter.  Backporting these modifications to BSF might be 
problematic, or impossible.  My bet is that the BSF developers would be 
willing to adapt these changes to the BSF layer, as opposed to the engine 
layer, given that the changes offer support for secure script execution 
which is a useful thing.  As to size, bsf-2.2.jar weighs in at 104 KB which,
  while not insignificant, pales in comparison to fop.jar.

The combination of Batik and XSmiles (or SVG and XForms) looks to have a 
ton of promise.  If both projects were to move to the BSF this promise 
could be realized much sooner and with greater ease.

Thanks for reading this far.

Jason Foster


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

Re: [developers] Re: XSmiles, Batik, and BSF

[Jason Foster <ja...@uwaterloo.ca>]

> a. Security. To get Rhino to run securely (which we need for a browser), 
> we had to do some heavy lifting and I am not sure how (or if) that would 
> be done in BSF. May be it is possible, I just do not know how it 
> translates.

I've got to believe that these security issues would be of interest to the 
BSF development team as well, given that your usage scenario can't be that 
uncommon.

> b. License. Last time we looked at it, the license was problematic for 
> inclusion in the distribution. I cannot recall what the issue was exactly,
>  but I remember there was a stopper.

The Cocoon project is shipping with the BSF jar and as an Apache project 
should be operating under the same constraints as Batik.  So at a guess 
either Cocoon has missed a license issue or the license is acceptable.

> However, it would be nice to have ability to run all the script languages 
> BSF supports (but note that the Batik architecture already lets you add 
> new scripting languages easily).

Fair point.  My concern is making sure that Batik scripting can 
interoperate with the scripting of its host.

> I am 100% with you on the combination of SVG and XForms and it would be 
> good to combine Batik and XSmile. The DOM issue is a pretty difficult one 
> and requires work.

Has this issue come up before?  It strikes me that it would come up 
whenever Batik is used in an embedded context.  I haven't looked, but it 
makes me wonder about Batik's use cases and whether it is being used more 
as a standalone product than an embedded component.

As I watch the W3 develop all of these interesting representation standards 
(MathML, SVG, SMIL, XForms) I'm starting to wonder if there has been any 
thought given to how to develop a modular approach to implementation?  I 
know that XSmiles has developed an extensible architecture, but they have 
also implemented most (if not all) of their modules which makes integration 
easier.  The real tricks seem to come when merging two scriptable, 
DOM-based implementations from different development teams.

Jason


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

Re: XSmiles, Batik, and BSF

[Vincent Hardy <vi...@sun.com>]

Jason,

Thanks for your suggestions on using BSF. The two major issues that I 
can see with integrating BSF are:

a. Security. To get Rhino to run securely (which we need for a browser), 
we had to do some heavy lifting and I am not sure how (or if) that would 
be done in BSF. May be it is possible, I just do not know how it translates.

b. License. Last time we looked at it, the license was problematic for 
inclusion in the distribution. I cannot recall what the issue was 
exactly, but I remember there was a stopper.

However, it would be nice to have ability to run all the script 
languages BSF supports (but note that the Batik architecture already 
lets you add new scripting languages easily).

I am 100% with you on the combination of SVG and XForms and it would be 
good to combine Batik and XSmile. The DOM issue is a pretty difficult 
one and requires work.

Vincent.

Jason Foster wrote:
> I've been lurking on both of these mailing lists for a little while, as 
> well as some of the SVG lists, and would like to make a suggestion to 
> both development teams.  In the immediate future I can't offer more than 
> the suggestion and discussion, but if things go well I might be able to 
> offer some warm (student) bodies.
> 
> The possibilities afforded by a combination of SVG and XForms is 
> starting to gain some traction.  The SVG community is investing *way* 
> too much time putting together interface widgets that accomplish much 
> less than XForms (except maybe for tree controls).  There is currently 
> no easy way to emulate, in a cross platform manner, the simple XSmiles 
> demo of a searchable map (using SVG and a text edit control).  
> Unfortunately the XSmiles team is currently not using the Batik framework.
> 
> The good news is that according to Mikko Honkala the XSmiles team has 
> moving to Batik on their TODO list.  The bad news is that according to 
> Juha Vierinen there are currently a few major stumbling blocks:
> 
>> The scripting is one issue (we have our own, and they have their own). 
>> I guess that this could be solved by letting the two scripting scemes 
>> co-exist. Another issue is the SVGDOM implementation. It would be nice 
>> to have only one DOM tree for the rendered document. Otherwise we 
>> would have to keep two different trees in memory, and keep them 
>> synchronized.
> 
> 
> I can't speak to the DOM issues, but I would like to suggest that both 
> teams adopt the BSF as their scripting implementation.  Once both teams 
> has transitioned to the BSF, merging the scripting support should be 
> (knock on wood) straightforward.
> 
> Based on a recent post to the BSF mailing list, I know that the XSmiles 
> team is aware of the project.  According to a search of the batik-dev 
> archives, BSF integration was being discussed a year ago, but has never 
> materialized.  Given that both projects have looked at BSF, and neither 
> project has dismissed it as being inappropriate, it looks like a 
> possible winner.
> 
> Moving both projects to BSF offers a number of advantages.  Foremost 
> among these is interoperability.  An embedded Batik would benefit from 
> being able to hook seamlessly into the scripting support of its host 
> (say, XSmiles).  BSF support also offers the advantage of not having to 
> worry about updates to the Rhino and Jython packages.  A final thing 
> that BSF offers, although not necessarily a practical one, is the 
> ability to script SVG using Ruby, which would just be cool :)
> 
> The primary disadvantage of BSF that I can see, beyond having to replace 
> the plumbing, is that Batik seems to have done some heavy customizing of 
> the Rhino interpreter.  Backporting these modifications to BSF might be 
> problematic, or impossible.  My bet is that the BSF developers would be 
> willing to adapt these changes to the BSF layer, as opposed to the 
> engine layer, given that the changes offer support for secure script 
> execution which is a useful thing.  As to size, bsf-2.2.jar weighs in at 
> 104 KB which,
>  while not insignificant, pales in comparison to fop.jar.
> 
> The combination of Batik and XSmiles (or SVG and XForms) looks to have a 
> ton of promise.  If both projects were to move to the BSF this promise 
> could be realized much sooner and with greater ease.
> 
> Thanks for reading this far.
> 
> Jason Foster
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org