[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
> Hmm. Could a parts database utility be constructed to be logically
> inserted ahead of the gnetlist back end (using -l or -m options)?
My thoughts are that such information needs to be available at
schematic capture, netlisting, *and* layout. I choose parts at all
levels...
> Plug-in...
Hence http://www.delorie.com/pcb/component-dbs.html
"How is the database stored? I'm not going to specify that - it's
irrelevent. What's important is how the app interacts w ith the
database. My idea is that there's a well-documented ABI for a
plug-in that provides the data. That way, the user can provide
whatever back-end they prefer - perl script, CSV files, SQL
database, web query - whatever. Even an aggregator that merges
multiple plug-ins into a single one. The ABI works something like
this:
* The app sends the plugin the list of attributes for which it
already has values, along with those values. Some of these
attributes may be project-global.
* The app sends a list of attributes for which it wants a list of
possible values (an empty list implies all available
attributes).
* The plugin sends the app a list of those attributes, each with a
list of possible values for those attributes."
Thus, gschem could query the database for available LED colors,
gnetlist could provide default 0603 packages for most resistors, and
PCB could swap out a TSSOP for a VSSOP if space required it.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user