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]
