We use a separate tomcat instance which loads in Batik. This is not because we run PHP, but rather to reduce memory contention with the web serving portions. Same sort of problems though. I'd suggest you also run an instance of tomcat, instead of GNU Classpath. Bind tomcat to a different port or ip address. You can pass parameters to it via the URL parameters, or even POST large binary values if that's your game. Then you can run a servlet and have Batik already loaded in mem. This will be a lot faster, both in implementation and while running. Many less context switches I'd say. If you truly need to unify the http space, say for AJAX calls or whatever, look at a squid proxy upfront in httpd accel mode with some regexp subprocesses to rewrite the url and fetch from the batik tomcat where necessary. Or if you are using Apache, look at mod_rewrite. Terry.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mon 24/10/2005 23:54 To: [email protected] Cc: [email protected] Subject: Re: batik with GNU Classpath Hi Brion, Brion Vibber <[EMAIL PROTECTED]> wrote on 10/24/2005 04:03:47 PM: > Anthony Green wrote: > > The Wikipedia people want to use batik on gcj/GNU Classpath to render > > svg for wikipedia entries, but they're stuck on this as well. > > Note that this isn't just our free software fetish. ;) Batik is pretty > big, and we need to run it as a shell-out from a PHP program on form > submission, so ahead-of-time compilation would be real nice. Why not setup Batik as a 'service' so it doesn't have to load up each time (I suspect even a binary of Batik will take a while to get up and running). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
