kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/08/2014 01:45 AM, Dick Hollenbeck wrote:
> On 05/06/2014 05:41 PM, Cirilo Bernardo wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: John Beard <john.j.beard@xxxxxxxxx> To: Kicad Developers
>>> <kicad-developers@xxxxxxxxxxxxxxxxxxx> Cc: Sent: Wednesday, May 7, 2014 4:28 AM 
>>> Subject: [Kicad-developers] Forward-compatibility in s-expression formats
>>>
>>> I think it would be a good idea to allow unknown fields in the s-expression formats
>>> so that an older KiCad doesn't choke on things it doesn't understand, and doesn't
>>> need to.
> 
> 
> I think you should just pay the upgrade fee and use the newest software.  Having older
> software accept file which whose design has not happened yet, sounds like a tough nut and
> of little value.
> 
> Future proofing is goofy when you can simply recompile for free.
> 
> 
>> I was thinking of the same sort of mechanism; after all, it's been done numerous times
>> before (including for example the PostScript and PDF specifications).
>>
>>>
>>> Ignoring *every* unknown field might also not be the best idea, in case there is one
>>> day a field which an older KiCad can't understand, but should realise "no, this means
>>> I can't use this footprint". So maybe also a "fp_version" field, which, if missing,
>>> is assumed to be "1". Then, if a future footprint declares "(version 2)", because it
>>> knows it contains features a version-1 KiCad will misinterpret, that version-1 KiCad
>>> can say "sorry, I'm version 1, you need version 2 or higher". In this case, it would
>>> be nicer to not set the version to 2 if you didn't need to, so version-1 KiCads can
>>> use the footprint.
>>>
>>
>>
>> In general, future versions should always act correctly with data from a previous
>> version. Allowing a future version to say "hey, I'm not going to read this older format
>> because I use the key 'qwijibo' differently" just doesn't make sense. Bumping the file
>> version each time new required features are added to KiCad is sensible; the
>> implementation may be a bit tricky though if a number of features are introduced as
>> patches over a number of weeks or months.
> 
> 
> There is a DOM parser in the project.  If you want to load an s-expression into the
> boost::property tree that can be done in about 2 lines of code.
> 
> Then you can pull from the tree into your actually useful datastructures.  What you end up
> with is going to be slower and will consume more RAM, other than that it is like working
> with XML with a DOM parser instead of what is closer to a SAX parser.

See tools/property_tree.cpp

But again, working from the property_tree directly is suitable for only a minority of
situations, and when its not suitable, this means copying.  But either copying or
navigating the property tree are both way slower than what we are doing now.

But here's a case where the DOM parser could make sense: in the handling of small
s-expression documents like those which could soon flow in the KIWAY.  I don't see a lot
of point in writing a parser to handle up to 20 tags or so.  Simply using a propert_tree
too look for what you are expecting and ignoring what you are not makes sense to me in
that situation.

This is very much similar to the kind of design decisions that go into deciding whether
you are going to use a DOM or SAX parser when working with XML.



> 
> 
> This is a lot of cost so that old software can read datafiles which have not been invented
> yet.  The cost of replacing the old software is zilch.
> 
> You could also try and future proof the software by adding all the features you will ever
> need now.  Then we can through our compilers away and live happily ever after.
> 
> 
> 
> 
>> - Cirilo
>>
>>
>> _______________________________________________ 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
>>
> 
> 
> _______________________________________________
> 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
>