kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.


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
>