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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
