kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
>>>> 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.

I sorry about the confusion but my only point was how well it is
supported on Windows. I was hoping you or someone else on the list knew
of an example of where it is being used on Windows and Linux so I could
get an idea of how difficult it would be to support in in Windows should
we decide to use it. There is no doubt that there is enough developer
talent in Kicad to make DBUS work on Windows. I am just trying to get a
feel for the effort involved. That information would be helpful in any
decision making and planning.

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

Perhaps Kicad will be the project that moves this merge forward.

Wayne

> 
> 
> Dick