Re: gEDA-user: Parts DB API

[Steve Meier <smeier@xxxxxxxxxxxxxxxxxxx>]

Levente's Model?

in -> process -> out

-----------------------------------------------------------------

1) sch, bom -> gschem (with db interface)-> sch, bom, ps

2) sch, bom -> gattrib (with db interface) -> sch, bom

3) sch, bom -> netlister -> netlist

4) netlist -> pcb -> gbr, cnc, ps, eco

5) sch, bom, eco -> netlister -> sch


Steve Meier wrote:
> in -> process -> out
>
> -----------------------------------------------------------------
>
> 1) sch -> gschem -> sch, ps
>
> 2) sch, bom -> gattrib (with db interface) -> sch, bom
>
> 3) sch, bom -> netlister -> netlist
>
> 4) netlist -> pcb -> gbr, cnc, ps, eco
>
> 5) sch, bom, eco -> netlister -> sch
>
> I use netlister very liberally when I mean a libeda application that can
> run scripts to manipulate the data structures and run scripts to output
> in most any file format.
>
> eco is a file that has the difference between the input netlist and the
> final netlist that represents the board
>
> Steve Meier
>
>
>
>
>
> DJ Delorie wrote:
>   
>>> For the time being, however, I don't see any reason not to stick to
>>> using some sort of external helper programs for actually accessing
>>> the database, as long as we can get the UI and basic Scheme API
>>> nailed down.
>>>     
>>>       
>> I've argued in the past that gattrib should be responsible for
>> attributes, not gschem.
>>
>> And, there's no reason why the attributes need to be in the schematic!
>> We can store them in the BOM.  There's a pleasing symmetry to it:
>>
>> gschem uses *.sym files to make *.sch
>> gattrib uses db files to make *.bom
>> pcb uses *.fp files to make *.pcb
>>
>> The only interesting change is to gsch2pcb, which needs to read a
>> *.bom file in addition to the schematics.
>>
>>   
>>     
>>>> The symbol files should be as light as possible, and we should make them
>>>> heavy by adding information coming from the database.
>>>>       
>>>>         
>>> Totally agree.
>>>     
>>>       
>> I agree symbols should be as light as possible, but "adding to them"
>> isn't a requirement - we can store them in the BOM.  If we store the
>> attributes there then we also have a clue about which attributes came
>> from which programs, and the bom can store more than just a name/value
>> pair - it can store an "origin" value (how the value got chosen), for
>> example.
>>
>> I think the only things that need to be added to the symbols
>> themselves are things that need to appear in the schematics - like pin
>> numbers.  We need a way to assign pin numbers to labelled pins so that
>> you can see in the schematic which pins are which.  Especially if we
>> get back annotation working.
>>
>>
>> _______________________________________________
>> 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