Server Mode: Option to run Inkscape as a command line server

[Henrik Bohre]

This patch adds a --server command line option which makes Inkscape run in server mode accepting new command lines from stdin.

Note that the accepted command lines are identical to the common command lines, except that the inkscape command is omitted. Note also that some commands will quit the server, such as --version which exits on completion.

Example run:
inkscape --server
Inkscape 0.46+devel server mode. Type 'quit' to quit.
>/tmp/test.svg --export-dpi=300 --export-png=test.png
DPI: 300
Background RRGGBBAA: ffffff00
Area 0:0:262:173 exported to 874 x 579 pixels (300 dpi)
Bitmap saved as: test.png
>quit
done

[rejon (rejon)]

I don't think this option should be called --server, but --interactive since its basically an interactive terminal for doing commands.

Bohre, why do you think this patch is good too? If you are desiring to do batch operations, its easy to simulate the features and this just adds more bloat to inkscape.

I'm more interested in a patch that truly make inkscape run as lean as possible from commandline and/or in daemon mode for minimized startup/shutdown times...

[Henrik Bohre (bohrax)]

Hi Rejon. Thanks for your comments.

Yes, --server might be a bit misleading. Perhaps --cli is even better? --interactive may clash with regular GUI work? I welcome suggestions.

I agree that the patch may not be used by the everyday user, but it is quite minimal. The reason for me wanting to add it, is that it cuts down the processing time considerably when handling large number of conversions. It addresses a performance issue, more than adding new functionality.

As an example I could see it running as a web server plugin, making it possible to dynamically render SVG drawings dependent on input from a web page. This borders to impossible if you need to start the application for each request.

I've looked somewhat into using Inkview as a leaner alternative, but I think it needs quite some job to remove basically unneeded libraries from it. Given the design goal of Inkscape being an editor rather than a lean renderer it may be understandable.

On the downside, I've found that the SPDocument code leaks which still makes it impossible to handle more than a couple of thousand documents. It's bee looked into.

[Henrik Bohre (bohrax)]

The SPDocument leak is probably related to https://bugs.launchpad.net/inkscape/+bug/235371 and https://answers.launchpad.net/inkscape/+question/30097.

[rejon (rejon)]

On Wed, 2008-08-20 at 06:27 +0000, Henrik Bohre wrote:
> Hi Rejon. Thanks for your comments.
>
> Yes, --server might be a bit misleading. Perhaps --cli is even better?
> --interactive may clash with regular GUI work? I welcome suggestions.

Interactive is what is usually used on cli scripts...either is better
than sever though.

> I agree that the patch may not be used by the everyday user, but it is
> quite minimal. The reason for me wanting to add it, is that it cuts down
> the processing time considerably when handling large number of
> conversions. It addresses a performance issue, more than adding new
> functionality.
>
> As an example I could see it running as a web server plugin, making it
> possible to dynamically render SVG drawings dependent on input from a
> web page. This borders to impossible if you need to start the
> application for each request.

How could an app plug into this? I think it running in daemon mode might
be good, but curious how you think to get commands to inkscape should be
handled.

> I've looked somewhat into using Inkview as a leaner alternative, but I
> think it needs quite some job to remove basically unneeded libraries
> from it. Given the design goal of Inkscape being an editor rather than a
> lean renderer it may be understandable.

Yes, what would be great is to make somethink like inkserve and strip
out unnecessary crap so we have an awesome svg renderer usable as you
(and I both) want.

> On the downside, I've found that the SPDocument code leaks which still
> makes it impossible to handle more than a couple of thousand documents.
> It's bee looked into.

Yes, sucky!

Jon

--
Jon Phillips
San Francisco, CA + Guangzhou + Beijing
GLOBAL +1.415.830.3884
CHINA +86.1.360.282.8624
<email address hidden>
http://www.rejon.org
IM/skype: kidproto
Jabber: <email address hidden>
IRC: <email address hidden>

[Henrik Bohre (bohrax)]

Hi Jon,

not sure which language you prefer, but from e.g. Python it's very easy to connect with the subprocess module. You just open the inkscape process with the --interactive-cli(?) switch and get pipe handles to stdin, stdout and stderr that you can write and read from as regular files.

I can give you a code example if you're interested.

Best regards
Henrik

[Buliabyak-users (buliabyak-users)]

Haven't tested yet but I vote for the patch. Great idea. I think the --server name is better but I don't mind --interactive or --cli-interactive either.

And Henrik, if you help us fix those leaks it would be huge! :)

[Jon A. Cruz (jon-joncruz)]

I've given it a quick review, and while the overall is looking good, there are a lot of little details that need to be figured out and addressed before we commit. One quick example is hardcoded buffer sizes for paths and suck. There is a hardcoded array of only 1k, but Linux usually may pass up to 4k, and BSD has been seen to use 16K. Also the current code will not operate correctly on MS Windows.

[Henrik Bohre (bohrax)]

About Windows compatibility: Is it the GUI/console mode issue, or is it something specific wrt the patch?

About the command line buffer: A quick fix would be to use ARG_MAX for Linux/OS X. Windows has 8191 as a limit in cmd.exe and 32767 for CreateProcess. Not sure what the macros are called.

However, hogging 128 kB seems a bit wasteful. The alternative is to allocate new buffers dynamically. Is that something that would increase the chances of getting the patch approved, or are there other blocking issues?

[Jon A. Cruz (jon-joncruz)]

Patch cleaned up and applied in revision 19846.

[Dusan Maliarik (dusan-maliarik)]

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.