← Back to team overview

kicad-developers team mailing list archive

Re: Re: New library file format


I meant no offense, and I am certainly not trying to cast aspersions on your capabilities. I have no doubt whatsoever that you are fully capable ofbuilding whatever you propose. My point, though badly expressed, was simply that it is very easy (and I have seen it, indeed participated in it, firsthand) to over-engineer something to support all kinds of potential use-cases and re-use by others, and then when it is deployed and the dust has settled, even though it is working as advertised and you did a fine job and everybody's happy, the *actual* *use* of your wonderful invention is limited to such a small subset of what you designed that you could have saved a lot of time and effort by building something much simpler in the first place. Now, since I can't read your mind, and don't know exactly how you are planning to hook the plugins up, I cannot presume to know whether you are anywhere near falling into this particular trap or not. It's just a cautionary tale.

You are protecting me from myself? You sound like my government.... just kidding. Early in my career, that was my middle name, over-design. But here we are just talking about an API that has to exist anyway. I'm just saying formalize it, like you would publish the dimensions of a building foundation for the next subcontractor who is putting up walls.

It takes about 4 lines of code in CMake to build a DLL or DSO.

So I absolutely agree with you that user experience is paramount, but in so doing I put the plugin manager in the same category as the file format-- a nice piece of technology that might solve part of the problem.

Personally, if I were doing this, though (but of course I'm not, and I know that doesn't give me a vote :) being the lazy programmer that I am, I would eschew the plugin support for a much simpler architecture, and try toleverage existing web infrastructure as much as possible. For example, itwould be relatively easy to add the ability to open a socket to read a webpage, and the ability to parse HTML and look for special tags that indicated a valid library was inside.
Your HTML parser could be done in a "usage API" plugin, so your "implementation" of a read only library part retrieval mechanism can have its place, one that the plugin architecture provides for you. So your idea is not mutually exclusive with mine.

Absolutely agreed. It should be a piece of cake with the available lower-level data serializer/deserializer you describe.

Now, you've got google finding your parts for you, you've got a web page with pinouts and text and 3D models, or however fancy the designer wants to get in communicating his library to humans, and KiCad can load it from the same URL the user uses to look at it.

Your documentation needs shift. Sure, you're documenting a file format(which you really should do anyway for the cache file), but instead of documenting an API, you are documenting how you containerize your file inside an HTML document with a few tags.

A guy who uses the library editor to make one part can now share it with the world without having to write or understand a KiCad plugin -- he justneeds basic HTML skills.
The library editor becomes a library specific tool under my vision. In some libraries parts could be stored in a database and autogenerated with fortran or front panel switches, or chipmonks (pun intended). It does not matter, as long as the usage API is there to pull parts out into Kicad, and then from those in RAM structures we can cache the parts on disk. Writing a plugin does not have to be hard, especially if there were samples. As always, there are people available for hire to do these things.

I can see your point, and I agree that the plugin architecture can removethe debate about where/how libraries should be stored from KiCad development, and let non-core developers play with their own visions more easily. So, if the plugin architecture you are envisioning is a small enough effort,you should build it and let them come. It's only if it starts to be big enough to start costing serious development time that you should blow it offand decide to hard code support for "files and XXX", where "XXX" is web, or database, or whatever.

I have to admit that I did not understand, at first, that you were proposing a standard serialization/deserialization mechanism that *could* be common (at least reused) by each plugin. So I was worried that a plugin would be more work than it appears you meant for it to be.

Since you have expressed that there should be a canonical text format forlibrary 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.

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.


Follow ups