kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/08/2014 02:18 PM, Dick Hollenbeck wrote:
> On 05/08/2014 01:31 PM, John Beard wrote:
>> On 08/05/14 15:53, Dick Hollenbeck wrote:
>>>
>>>> That's exactly what I mean - older versions of KiCad should be able to 
>>>> ignore, but retain, unknown data.
>>>
>>> This sentence has two concepts in it.  One is fools gold, the other is poorly expressed.
>>>
>>> 1) An older kicad should load a data file that is has never seen before.
>>
>> Is this fools' gold? A PDF reader from 2005 would probably still load a
>> PDF made by newer software, even if there are new features it cannot
>> understand. It might say "You can't see the embedded 4D MegaContent
>> (TM), upgrade to a version that support PDF spec v5.6 for that", but
>> it will show you what it can. You'd be annoyed if it didn't, it would be
>> like Flash needing the latest version to watch your video, without the
>> excuse that is necessary to implement the latest and greatest DRM fad.
>>
>>> The motivation should be that you want the flexibility to solve a specific problem.
>>
>> The motivation is that I want the flexibility to add a field to a
>> .kicad_mod file, that still allows someone else to read the footprint,
>> if they don't *need* to know about that field. Currently, that will
>> cause THROW_PARSE_ERROR(), and they get nothing.
>>
>>> But it should not name future proofing as the motivation, because you don't want to
>>> upgrade.  That's the part that gives me conceptual grief.
>>
>> It's not because *I* don't want to upgrade, *I'm* to the one who's
>> hypothetically extended some aspect of the footprint format for my own
>> ends. It's because J. Random McTrunkBuild (or even his cousin,
>> McDistroVersion) shouldn't need to recompile with a patch from me to
>> read a footprint of mine which has my field "(user_sku 45443)" or
>> "(jedec_ref "SOT45")" in it, when he doesn't need or care about that
>> field.
>>
>> The current state is there no way for people (not intimately familiar
>> with the .kicad_mod format) downloading a footprint now to know if it's
>> compatible with their KiCad without loading the footprint and then
>> guessing that the "Expected...." message means the footprint contains
>> unknown fields, as opposed to being malformed.
>>
>> Forced recompiles are only free if your time is worthless and any
>> problems caused by running bleeding-edge PCB software in production
>> environments have zero cost.
> 
> 
> Submit a patch.
> 
> Hope it gets accepted.


Since your interest is limited to the *.kicad_mod file.  You can use the mentioned DOM
parser in your rewrite of the KICAD_PLUGIN::Footprint*() functions.

Please include comparative benchmarks with your patch submission.  If there's no
appreciable performance hit, then you have a chance getting the patch accepted.