kicad-developers team mailing list archive
Mailing list archive
Re: Re: New library file format
Dick Hollenbeck <dick@...>
Wed, 11 Nov 2009 08:50:38 -0600
Thunderbird 126.96.36.199 (X11/20090817)
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.
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 :)
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.
Your point that DBUS has to work on Windows is a good one.
Your point that others have to be also using it not as strong. (There
is a lot of code in Kicad that no other project is using, and it works,
So I will respect your first point, and do not put any weight on the
Does it work? I don't know. There is a daemon process that runs in
between all the other apps. If that process and all socket level APIs
that are used in the full unix port can be abstracted at their lowest
levels with some kind of platform agnostic thin library, then the merge
of windows support back into the mainstream DBUS library would be the
way to go. I have seen the posting about doing this merge sitting there
for about 2 years now. It is probably not going to happen unless
somebody pushes for it. That is the ideal direction for the Windows
port IMO, simply get rid of it in favor of the genuine DBUS code base.
On the other hand, the Windows support may already work. Maybe we
should put a feeler out on the windows mailing list.
But like most things in software, where there is a will there is a way.
I fully concur that Windows needs to be supported, so you can assume
that any commitment to DBUS is also a commitment to the Windows fixing
and testing of DBUS.
What I grasp onto most tightly in this discussion, is that DBUS is used
everywhere now in a desktop linux distribution, so that code is very
mature, stable, and well supported. And this leads me to believe that
the best path forward for the Windows support is for it fight its way
back into the main code base, by use of abstraction at the lowest
platform specific layers.