On 05/06/2014 05:41 PM, Cirilo Bernardo wrote: > > > > > ----- Original Message ----- >> From: John Beard <[email protected]> To: Kicad Developers >> <[email protected]> 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 : > [email protected] Unsubscribe : > https://launchpad.net/~kicad-developers More help : > https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
