[Scribus] What do you think about a Scribus Server?

[Craig Ringer]

Matthias Schmitt wrote:
> Hello,
> 
> I would like to add to the discussion of new ideas for the "Google  
> Summer of Code 2007".
> 
> What do you think about a Scribus Server version? The basic idea is  
> similar to the one of the Adobe InDesign Server. A Scribus Server  
> would be a server based publishing solution without any user  
> interface. Documents would be generated by connecting to the server  
> and sending XML messages.

*LOTS* of work would be needed on the codebase to get it to the point
where it could support a long-running stable server. The Scribus team
has  been making improvements with a view to supporting this for a long
time, so the code is closer than it was. It's a frequent request and not
at all new.

Commonly associated ideas are are:
- Running scripts from the command line
- Command line driven document export (no GUI)

... and work towards those has also bought further-out ideas like a
server version closer.

A long-running server just takes the same idea and adds some
inter-process communication to make it happen without launching a full
new instance for each job - basically just a resource usage
optimisation. However, it must be MUCH more stable, be more careful
about long term memory handling issues like heap fragmentation, and more.

> - maximum language independence (you may choose any programming  
> language to connect to the server)

If IPC is implemented using something like XML-RPC or CORBA, then that's
definitely possible. It sounds much easier than it is, however, since
you end up having to either use a clumsy low level interface in each
language, or write language bindings for each language anyway.

There are possible solutions to this, like KDE's scripting framework,
but they come with their own problems in terms of dependencies to
platform libraries etc.

> It should be possible to fulfill any task with the server, which can  
> be done with the mouse driven UI.
> What do you think?

I don't think the last point is realistic in the near to mid future.
It'd involve instrumenting EVERY bit of functionality to a really high
level of detail - and at this point that's just not practical.

Hopefully Qt's D-BUS support will make it a bit better, especially if
someone comes up with higher-level interfaces to export API over D-BUS
(say, like DCOP did). However, that's largely used on *nix; win32 users
want COM interfaces, and Mac users want AppleScript/AppleEvent
interfaces. I'm under the impression that making all these use one
common interface is non-trivial, let alone actually writing up support
for them.

Even sticking to one interface, say an IDL-generated XML-RPC wrapper, is
still going to be a bunch of work. I don't think it's realistic until we
have a stable C++ API in place for use by plugins and scripts. This has
been a major "wanted" feature for a very long time, and is critically
important for many projects that want to expose more Scribus
functionality to various forms of outside access.

Until we have such an API, I'd stick with the basics of document
loading, export, form filling, etc in terms of automation support.

--
Craig Ringer