Isn't this --shell mode? I guess it is. First, it's a very good idea, second, the implementation sucks. There are many that would like to use Inkscape's excellent SVG renderer (it's better than WebKit, librsvg or batik) in a server environment. However, as it is now, it's only suitable for batch exports. I'm trying to wrap this in a python script and it's PITA. The only thing we can do is read one char. at a time, once it equals to '>', we know inkscape is done. If it crashes, we'll just block the system by trying to read from inkscape's stdout.
This is certainly not the way it should work. How did you came to this "shell" idea? IMHO the proper solution would be to include 2 binaries, one, say inkscaped, that would just sit in background and wait for requests from the other binary sending commands to it. This client program wouldn't consume any resource at all, it would just talk to inkscaped (sockets or whatever interprocess communication), and return either success or failure code. That way we can monitor inkscaped for crashes and don't care about it anymore in client code. That client program could either block until inkscaped comes to live again, or return a specific code.
Isn't this --shell mode? I guess it is. First, it's a very good idea, second, the implementation sucks. There are many that would like to use Inkscape's excellent SVG renderer (it's better than WebKit, librsvg or batik) in a server environment. However, as it is now, it's only suitable for batch exports. I'm trying to wrap this in a python script and it's PITA. The only thing we can do is read one char. at a time, once it equals to '>', we know inkscape is done. If it crashes, we'll just block the system by trying to read from inkscape's stdout.
This is certainly not the way it should work. How did you came to this "shell" idea? IMHO the proper solution would be to include 2 binaries, one, say inkscaped, that would just sit in background and wait for requests from the other binary sending commands to it. This client program wouldn't consume any resource at all, it would just talk to inkscaped (sockets or whatever interprocess communication), and return either success or failure code. That way we can monitor inkscaped for crashes and don't care about it anymore in client code. That client program could either block until inkscaped comes to live again, or return a specific code.