kicad-developers team mailing list archive

[Andrew Lutsenko <anlutsenko@xxxxxxxxx>]

Hi Brian,

I don't have any comments on specifics of the patch but I just wanted to
let you know that I'm looking forward to this work being merged.

Some time ago I suggested
<https://lists.launchpad.net/kicad-developers/msg38772.html> that KiCad
moved to protobuf based file formats and even done some proof of concept
work <https://github.com/qu1ck/kicad-source-mirror/tree/proto/proto>.
I wanted to go as far as fully integrate protobuf io plugins and add a
converter from legacy format to alleviate concerns about performance. But I
saw that SCH_IO_MGR is not fully implemented yet and decided to wait until
that is done and different file formats are truly pluggable.

I'm still reserving hope that I can convince core devs that declarative
format with vast language support and built-in strict parser is the way to
go. You can see my reasoning and follow-up discussion in the mail chain I
linked above. It might be of interest to you as well since converting
protobuf into compact binary format for storage in database would be ~3
lines of code.

As soon as your changes to finish SCH_IO_MGR get in soon I will continue my
work on protobuf format for schematic and symbol libs.

Regards,
Andrew


On Mon, Mar 11, 2019 at 2:46 PM Brian <lotharyx@xxxxxxxxx> wrote:

> My apologies; I realize I didn't do a very good job of describing my
> changes.  So:
>
> -- Legacy read/write extraction:
>
> This one's rather straight-forward.  I pretty much just yanked all the
> code from SCH_LEGACY_PLUGIN_CACHE specific to parsing / writing legacy
> symbol format and stuffed it into two static classes called
> LEGACY_PART_READER and LEGACY_PART_WRITER, found in
> legacy_part_serializer.h/cpp.  SCH_LEGACY_PLUGIN_CACHE now calls the
> static methods on those classes instead of having the code inside itself.
>
> -- Registry mechanism
>
> This one's a bit more involved and I welcome comment and discussion.
>
> Refer to eeschema/sch_io_plugin_registry.h/cpp.
>
> A new class called SCH_IO_PLUGIN_REGISTRY is a singleton which maintains
> a few indices of plugins.  In order to register plugins, each plugin
> class now exposes a static method called "create" which returns the base
> type SCH_PLUGIN *.  A pointer to this static method is provided to one
> of a few helper classes which lead to index entries created for the file
> extension and a string name.
>
> When a plugin is registered, the registry assigns it an ID number. This
> ID number replaces the SCH_IO_MGR::SCH_FILE_T enumeration. When a plugin
> is needed, the registry can be searched by name or extension, and has
> additional methods which expose the ID number for those places in the
> code that expected an integral value (for example, the symbol library
> table).
>
> All of SCH_IO_MGR's plugin-finding methods (FindPlugin, EnumFromStr,
> etc) are now pass-throughs to methods on SCH_IO_PLUGIN_REGISTRY.
>
> One area that does cause some concern for me is the conflation of
> libraries vs schematics.  I understand the reasoning, but it presents
> opportunities for extra complication when the same "plugin" handles
> reading both an entire schematic (with embedded symbols) and a library.
> For now, SCH_IO_PLUGIN_REGISTRY addresses this by allowing the same
> plugin type to be registered for multiple file extensions.
>
> A related area of concern is the collision of KiCad and EAGLE's
> schematic file extensions.  It isn't possible to differentiate them
> without looking inside, meaning that blindly passing the file extension
> to the registry to find the right plugin wouldn't work. Reading EAGLE
> schematics is pretty well encapsulated, though, so maybe it's fine to
> take a less-generic approach in that circumstance (e.g. we know it's
> EAGLE so use EAGLE plugin, rather than "finding" a plugin for ".sch").
>
> Anyway, there's the description.  Cheers!
> -Brian
>
> On 3/11/19 5:31 PM, Brian wrote:
> > Hello everyone,
> >
> > Thank you for the kind, informative, and speedy responses to my
> > previous message about schematic library code.
> >
> > Attached please find a gzipped patch generated by `git format-patch`
> > for initial review and comment at your ("y'all's") leisure.  This
> > patch both extracts legacy symbol serialization into a complementary
> > pair of classes, and implements a plugin registry mechanism that
> > handles things like telling the file browser a set of filters (in
> > addition to providing the means of finding plugins by extension, type
> > name, or numeric ID).
> >
> > I look forward to feedback.  I know there are some places that I felt
> > a little dirty about, and welcome the opportunity to discuss them
> > whenever a responsible party (e.g. the upstream author, maybe) has
> > some time.
> >
> > Cheers!
> > -Brian
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>