kicad-developers team mailing list archive
Mailing list archive
Re: [RFC] Symbol library file format
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Sat, 5 Jan 2019 08:17:37 -0500
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
On 1/3/19 11:24 PM, Simon Richter wrote:
> On 03.01.19 19:06, José Ignacio wrote:
>> think useful comments to the proposed format should see beyond the
>> actual low level representation of the data and talk about the overall
>> model being used to store it.
> tl;dr: That's a separate discussion.
> There are two schools of thought here, one that treats saved data as a
> protocol between two black box instances, and one that treats it as a
> serialization of the internal state.
> Both have advantages and disadvantages. The "protocol" approach allows
> changing internals more easily, and gives better compatibility between
> versions as changes to the file format have to be made deliberately,
> while the "serialization" approach gives us load/save basically for
> free, so we need a lot less code.
> The "serialization" model also requires us to generate the internal data
> structures from a more constrained language like IDL, as the marshaller
> needs to know when to follow pointers, and what members of an array are
> actually valid.
> I'm not sure there are generators that include support for spatial
> indexes, though, which is pretty much a requirement for fast rendering,
> so this is pretty much impossible at the moment, which places us in
> "hand written load/save code" territory anyway.
> We have also ignored diff/merge capability so far, which I believe is a
> good thing because it cannot really be done on a textual level (schemas
> are two-dimensional, PCBs are three-dimensional, so there is no normal
> form with a consistent ordering of elements that will make the files
> I fully expect both the internal model and the file format to change
> significantly in the coming years as new features are added. The main
> requirement for the file format is that it always needs to be possible
> to read older files in some way, and to recognize when a file is newer
> than the current parser understands.
> It might be a good idea to also have an "extension" mechanism, where we
> don't increase the version number when adding a new feature, but rather
> mark files that actually use the new feature, so files written by newer
> versions that don't use one of the newer functions can be read by older
> versions. This would also be another point for "hand written" load/save.
I've done some more investigation on this and I'm not convinced that
this is any better than our current implementation due to some of the
issues Simon mentioned above. I've also discovered there is also a
significant performance hit with the JSON reader. This is important
due to the overhead required when loading libraries. I appreciate the
information and protobufs are interesting but I am going to stick with
what we have and know versus what we don't know because I don't think we
have the extra manpower to experiment only to find out it doesn't suite
Description: OpenPGP digital signature