Re: gEDA-user: Parts DB API

[John Doty <jpd@xxxxxxxxxxxxx>]

On Dec 19, 2007, at 10:01 PM, Dave N6NZ wrote:

>
>
> John Doty wrote:
>> On Dec 18, 2007, at 2:32 PM, Peter TB Brett wrote:
>>
>>> "Rewrite the component library C & Scheme APIs, and make a new GUI
>>> for it in
>>> gschem" is achievable (just).  Ideally, I'd like to be able to do
>>> it in a
>>> tidy, self-contained way.
>>
>> May I suggest the following path to the future? I believe it's pretty
>> simple.
>>
>> Define a new attribute, "part=". Have it refer to an entry in a file,
>> "parts". Now, for example, I might attach the attribute "part=BCX70K"
>> to a light NPN transistor symbol. In the file "parts", I might place
>> the following:
>>
>> BCX70K
>> 	device=2N930JANTXV
>> 	footprint=TO206AA
>> 	pinnumber=1:C
>> 	pinnumber=2:B
>> 	pinnumber=3:E
>
> Conceptually I'm with you, but this is yet another flat file.  I'd  
> like
> a mechanism so that when the trigger attribute ('part=' in your  
> example)
> is encountered, it uses a script or helper to get the goods.  So if  
> you
> want a flat file, OK, the helper reads your flat file.  My helper will
> connect to mysql and use the attribute value in a SQL select  
> statement.

Fine with me. That's the kind of thing I was thinking of when I  
called this a "path to the future". Once you have the hook, you can  
have various ways to use it.

>
> Now, from there it is a short step to being able to join multiple
> attribute files.  If there is a global attribute selector that can be
> invoked at netlist time (or other extraction tool..) then a user might
> have an extra database column for attribute set, and a column for  
> revision.
>
> So, you might set attrset='prototype' attrsetrev='B1', and so the
> netlister does a select with "part='<something from symbol>' AND
> attrset='prototype' AND attrsetrev='B1'" and extracts the appropriate
> parameters.  A week later, you use attrset='production' and
> attrsetrev='A0' or whatever to get the information relevant to
> manufacturing ramp.
>
> Now, I suppose you could turn that around. Let's suppose gschem
> implements your suggestion exactly.  Then I would write a program that
> did the database query and produced the flat file to feed into the
> netlisting process.  Which of course can be automated with make.

That was more what I was thinking. This path has few advantages, I  
think:

1. It's simple to implement the flat file right away, I think.
2. The flat file is another place where one can inspect or intervene  
in the flow.
3. The flat file is a simple interface between BOM management and the  
schematic->netlist->layout flow. Modular.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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