kicad-developers team mailing list archive
Mailing list archive
Re: Re: New library file format
My two cents about DBUS:
1) I actually don't know if it's working on Windows (citing the website: D-Bus is very portable to any Linux or UNIX flavor, and a port to Windows is in progress.) I actually haven't it even installed on Linux so I have no idea of how much would be difficult to make it work, anyhow.
2) for the degree of IPC used by kicad (i.e. crossprobing. what else?) I think it's overkill like someone else (phinitnan_c) said.
That said, if the plan it to extend it for some kind of RPC (like that horrible DCOP used by KDE or ORBit for Gnome... both more-or-less failed at that) there is the lightweight XMLRPC that's supported more or less everywhere (not that I like XML, but given the range of languages and platform supported I would choose it for that kind of usage).
But if it all remains about crossprobing or little more, I agree that the current IPC is more than adequate.
I don't think there is much to this posting that I agree with, maybe
nothing at all.
Cross probing does not work in Kicad if you have more than one schematic
or board open at the same time. There is conflict because the server end
of the connection is the same port in each process, and then you get a
collision on the port number when the subsequent servers try and open
that port number.
DBUS is far superior to XMLRPC. It is a binary marshalling
architecture, with API query capability. It is not overkill, it is as
simple as possible, but not simpler, and Einstein would have found it to
be the right mix of capability and complexity.
DCOP failed because DBUS succeeded and won the battle.
It is everywhere in a contemporary linux distribution, dig deeper.
The geda guys are either using it or are poised to.
Most recently DBUS was brought up for usage in a part library access
plugin, it was not discussed in these most recent threads for general
incorporation into any place else, other than in one plugin. However,
the reason I bring it up again, is that it could very well serve a lot
of needs elsewhere within Kicad, for things like backimport, BOM
For example, lets say we can convince Alfons to add DBUS support to
Freerouter, so that we can do cross probing to freerouter back to both
PCBNEW and EESCHEMA? DBUS is the platform for that because it has a
Java language binding. It lets you talk to more than one other process
with a single broadcasted message, ergo the concurrent communication to
both eeschema and pcbnew from freerouter....
If you want to write a *competing* library access plugin that uses
XMLRPC behind the scenes, and as a way to pull parts off of a website,
you would be free to do so. Plugins would give you that flexibility.
The idea of the library access plugins is to create competition. Said
more accurately, it is to make Kicad a forum in which competition can
occur among library providers. And every part manufacturer is a
potential library provider.