kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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

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.

Best-
Seth