| Thread Previous • Date Previous • Date Next • Thread Next |
Lorenzo wrote:
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 generation, etc.
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.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
