In favour of DBus API:
2a) Exposing API via DBus is more difficult than just making a binding.
Is it? Only if one were experienced with one and not the other.
We have a scripting language binding. It's not great. It requires invoking from inkscape, a complete build of said language for mac and windows distributions and is very very poky. It's amazing we get so much out of it.
A better reason would be the lack of current DBus support in Windows. Although that could be solved in later Gtk releases/builds.
2b) It is a nightmare waiting to happen from a maintainability point of view.
Nonsense. What we support and ship has nothing to do with what other people ship. We can even tilt the scales by providing good documentation and examples for python. Overall this isn't a reason not to do DBus.
2c) The API of the existing DBus binding is really poor.
So is the python scripting 'binding'. That's not a reason to not do a job well.
2d) Every exchange of data would be a DBus call, and for an interactive tool the overhead would be too large.
Speed wise, it shouldn't be a problem. It's only really an issue when you start tying together mouse move events (which should just not happen) or rendering steps (which shouldn't happen). So long as all the comparability parts are in there and we support SVG and our API isn't poor quality, speed shouldn't be too much of an issue. Even inkboard could be remade using DBus if we did the API right.
If you think up something that wouldn't work, let me know here and I'll design a solution which the API would have in it's platonic form.
Martin,