Aaron & the Rest,
Hi again!
I should read up on DBus myself, really. It seems like a "lessons learned" framework based on previous designs.
For things like Corba, RPC, RMI, and the many other remote invocation protocols I've seen, you don't really need the entire framework running if you have the "server" application already running and the client knows the host/port where to look for it.
The framework is necessary for: 1) Discovery. Find the desired service (like with RPC's Portmapper)
2) Activation. Where ActiveX gets its name. If the server isn't already running, start it up and register it (maybe your own instance with parameters). For this, you need the framework itself to be running as a service on a well-known port. The client calls this, requests the port#, then calls the client. At first I thought that this wouldn't be necessary for Inkscape. But many users want to call Inkscape from the command-line and run something internal. It would be too much to require end-users to start Inkscape first before running command-line scripts.
Although it isn't necessary to provide all Inkscape functionality on all platforms, it would be good to prevent them from being weaker second-class implementations.
But this looks like a wonderful idea
On a different note: ================== Note that this is different from script-bound DOM. (Not Inkscape tools that manipulate DOM, but DOM itself.) That needs to be handled same-process. The code is mostly done, and is on an Hg server I have been using, if anyone wants to help on it. The final solution is to have an IDL-like XML description file of modules and interfaces to be bound. A small Java tool reads this and generates the C++ class to be bound, (.h defs and .cpp stubs) the script that binds to it, and the C++ binding code between them. This gets around the need to generate many thousands of lines of redundant code for the >164 SVG-DOM classes. Also helps prevent typos. And by generating, we can avoid C++ multi-inheritance problems, by MI delegation. For each inherited interface after the first one, we change "is_a" to "has_a", and avoid any diamond problems.
The generated C++ .h and .cpp stubs and script code currently all compile and link. Not bad for such a huge amount.
Email me or give me a shout on IRC/XMPP if you are interested in helping. I could use someone's advice on separating C++ interface and implementation. Like, the generator makes .cpp stubs for all classes and methods, but I already have most of the C++ implementation code already written (like normalize() or adopt()). How to automatically inject that code into the stubs? Put it in the XML file?
bob (ishmal)
On 7/18/2009 3:37 PM, Aaron Spike wrote:
Mat,
I saw your post about a DBus based Inkboard. I was wondering if you were aware of the work Soren has been doing with DBus in Inkscape for Google's Summer of Code. Without knowing a whole lot about how Inkscape can be made to communicate over DBus, I can only assume that there might be some overlap in your DBus integration work. I would like to see both of these projects succeed. Please take a look at how your projects can fit together.
Aaron Spike
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opporunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
========================= If I had words To make a day for you I sing you a morning golden and new I would make this day Last for all time Give you a night Deep in moonshine