kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> > > 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

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, 
eg. IPC)

So I will respect your first point, and do not put any weight on the 
second one.


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.


Dick