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