Re: gEDA-user: Has anyone used SSOP28.fp?

[Steven Michalske <smichalske@xxxxxxxxx>]

What I proposed is that,  we want to provide a parser that won't barf  
on properly formatted footprints that have newer features.

We have Pin, element line, Pad other parts to the footprints,  lets  
say we add  SolderMaskOpening( parameters ) and SolderPasteBlob 
( parameters )
An older version of PCB couldn't use those new definations   but,   
should it error out?

lets say we add a Require field  that says that it needs something


lets add:
	PolyPad ( parameters )
	SolderPasteBlob( param )


Element( stuff )
(
	Require( PolyPad )
	Polypad( stuff )
)


would cause a pcb that understood forward compatible footprints to  
fail because the PolyPad element is unknown to it.

but

Element( stuff )
(
	Pin( stuff )
	Pad( stuff )
	ElementLine( stuff )
	SolderPasteBlob( stuff )
)

would not cause a forward compatible pcb to fail loading the element,  
but would warn about SolderPasteBlob  not existing.

Element( stuff )
(
	Require( "SolderPasteBlob:Warning( Cannot properly create solder  
paste masks with this version of PCB\nSolderPasteBlob is not  
supported in your version of PCB please update if you use solder  
paste layers.\n):Disable(SolderPasteMask)")
	Require("PolyPads:Error(Cannot make PolyPads With this version of  
PCB.\nThey are required for this footprint.  Please install Version  
20080101 or later of PCB.\n))
	PolyPad( stuff )
	SolderPasteBlob( stuff )
)

This footprint would fail on not having PolyPad support, but would  
only warn on not having solderMaskSupport.


This could also work for plugins,  as the plugin only be loaded when  
it is required.  thus allowing for more extensibility?


I hope this cleared up my thoughts, about forward compatibility.

wikipedia has a nice entry on this... http://en.wikipedia.org/wiki/ 
Forward_compatible

Steve

On Jun 7, 2007, at 2:18 PM, L.J.H. Timmerman wrote:

> Hi DJ and all,
>
> First let's get this specified more in detail before this gets out of
> hand.
>
> What sort of content should the parser be agnostic of ?
>
> Kind regards,
>
> Bert Timmerman.
>
> On Thu, 2007-06-07 at 16:06 -0400, DJ Delorie wrote:
>>> Shouldn't the file format be forward compatible with a warning?  if
>>> an unknown parameter is introduced in the file format, pump out a
>>> warning and continue?
>>
>> The problem is that pcb's file format is entirely defined by a yacc
>> grammar.  I.e. the grammar says "expect FOO or BAR or GRILL here" and
>> if you give it any other token, you get a syntax error.  A better  
>> file
>> format would be something where the syntax is independent of the
>> content, like what the menu resource uses, or (gak) XML.  Then we
>> could parse the whole file into a data structure (all at once or
>> piecemeal), and interpret (or not) the data we get.
>>
>> Perhaps we could change the parser to be content-agnostic, though.
>>
>>
>> _______________________________________________
>> geda-user mailing list
>> geda-user@xxxxxxxxxxxxxx
>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user