← Back to team overview

kicad-developers team mailing list archive

Re: Patch: Legacy symbol read/write extraction; SCH_PLUGIN registry mechanism


Am 2019-03-12 11:37, schrieb Brian:

I think some discussion is in order to decide on which ideas
should make it into a unified plugin registry (something I'm
definitely in favor of and would be happy to contribute to the

Thanks for looking into this Brian!

1.  What's the right thing to use as a public unique key?  I like
strings because they can be done in a decentralized fashion and a
plugin writer needn't touch anything but his or her own code, but of
course the down side is there must be some means of preventing
collisions, e.g. two different plugins can't register themselves both
as "EAGLE".  Get many plugins and it starts to become troublesome to
find out what keys are already in use, which is an argument in favor
of some form of central authority.  This could simply be a header with
a set of #defined string literals.

These are not externally defined, so its probably equivalent. If you do propose a decentralized implementation, we should also add a unit test that loads all implementations and checks for collisions. I suspect the issue of namespace collision is easily addressed by standard suffixing e.g. EAGLE_SCH_7, EAGLE_PCB_9, etc.

2.  What to do if multiple plugins might want to work on files with
the same extension?  Maybe we take the approach of invoking plugins in
a sequence until one reports success?  That might not be too painful
if files are easily differentiable without reading too far into them.

Sounds reasonable. Plugins should first check that they can parse the version code before proceeding.

3.  Where does this unified code live?  common?  I think I'm correct
in guessing we don't want to introduce link dependencies between the
major targets (e.g. between eeschema.kiface and pcbnew.kiface)

Common makes sense to me. The exception would be if it is header-only you would place it in "include".

As an aside, I'm going to separate my initial submission into two
separate patches (which I probably should've done from the start) so
that the extracted legacy read/write can be merged (upon approval,
obviously) without waiting for us to settle on the details for the
unified plugin registry.

Thanks! Also, no need to gzip unless the message is getting rejected for size.