kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

phinitnan_c wrote:
> 
> --- In kicad-devel@xxxxxxxxxxxxxxx, Wayne Stambaugh <stambaughw@...> wrote:
>> Dick Hollenbeck wrote:
>>
>> <<< snipped >>>
>>
>>>> Since you have expressed that there should be a canonical text format for library data, the very first plugin I would like to see is one which can invoke an executable in a separate process and communicate with it via stdin/stdout. Then I can build my real plugin underneath the plugin manager in Python :)
>>>> 
>>> Well that would give you a byte stream, but no defined way to marshall 
>>> arguments. Why not simply go through DBUS, it was invented precisely 
>>> for this problem space. But I'm not saying do the formal usage API 
>>> (definition) in DBUS, but rather keep that as a C++ point of departure. 
>> Dick,
>>
>> I took look at DBUS documentation over the past few days so I could at
>> least try to see where you were thinking about going code wise. DBUS is
>> definitely an interesting way to solve the IPC problem. The fact that
>> it seems to have well supported set of language bindings is definitely a
>> plus. The only caveat I see is it's support on Windows. I download the
>> MinGW archive of DBUS from sourceforge to see what the differences where
>> between the Windows version and the unix version and how difficult it
>> would be to support in on Windows. The archive appears to be corrupt so
>> I couldn't install it on my system which makes me wonder how well
>> supported DBUS is on Windows. There is mention of an eventual merge of
>> the windows version with the main code base. Do you know of any good
>> examples of a project that has used DBUS cross platform? I know Windows
>> is not your favorite platform ( I'm shooting for the understatement of
>> the year award ) but I don't think abandoning Windows support it is an
>> option for Kicad just yet. ;)
>>
>>> The usage API could be done in a *.h file or two, and then Doxygen could 
>>> be ran against it to generate a nice programmer's document. Perhaps the 
>>> licensing model should allow closed source on the API, so somebody can 
>>> implement a closed source plugin. Then maybe TI or somebody will step 
>>> up and write a plugin so they can beat up on their competitors among 
>>> Kicad users, who eventually will take over the world.
>> Oh no! Not another world domination proclamation.
>>
>> Wayne
>>
>>>
>>>
>>> Dick
> 
> Wayne,
> 
> Why do we need DBUS? wxwidget own IPC doe not work?

I'm not sure which wxWidgets IPC class(es) you are suggesting. If you
are talking about wxServer, wxClient, wxSocketClient, and/or
wxSocketServer, these are very low level IPC classes. It would require
a lot of work to implement the same level of functionality that DBUS
has. DBUS is a much higher level implementation of IPC (someone correct
me if I am wrong here). It allows you to define interfaces so that
every implementation of that interface (think API here) must support it.
This allows you to create multiple versions of the same interface that
will be transparent to any client that connects to it. Language binding
support for DBUS is also very good. Once the interface is defined, it
doesn't matter what language you use to implement it. It will look the
same to any client that connects to it. This only scratches the surface
of what DBUS can do. You can check out the DBUS documentation at:
http://www.freedesktop.org/wiki/Software/dbus. I really don't think
there is anything even close to DBUS in wxWidgets but I could be wrong.

Wayne

> 
> Tony