Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")

[Armin Faltl <armin.faltl@xxxxxx>]

> I'd avoid data base solutions for footprints, symbols, simulation models and 
> the like. 
>   
Appart from my attempt to come up with my own table layout, I try now to 
get gparts working.
It's an independent tool like gattrib and you are free not to use it.
The idea of the tool is, to describe the relations between the entities 
you mention.
You are also free to do searches among the thousands of little packets 
some of them
with wrong lables as of now by hand.

> * Unless there are excellent import/export functions, a data base is an 
> additional obstacle to collaboration. These functions need to be written and 
> maintained-
>   
Inventing yet another cryptic file spec to describe the relations is 
even more obstructive.
> * Only a very small subset of the operations available on file systems is 
> present by default in data bases. Just to get the same level of user power 
> as with files, a major effort of data base scripting is needed.
>   
???
> * A data base can easily be corrupted on update of the data base driver.
>   
A file backend driver on changes of the file format can mess up as well, 
esp. if one tries
to reuse some parts of the parser. So can format converters of any kind.
> * Open source data base drivers like postgres or mysql may be quite mature. 
> Compared to the stability of the unix file utils they still look shaky. And 
> fast moving.
>   
The implementations are evolving. The good thing is, there is an 
ANSI/ISO-standard called SQL99
and that is stable and more than sufficient to describe what we need.
> * A data base would add a major dependency to the already significant set.
>   
True. For me still a lighter burden, than to implement the functionality 
of a database engine.
> * The number of all objects in the library is fairly moderate. All symbols 
> and footprints from the distribution plus all of gedasymbols are currently 
> about 4300. This can easily be handled by a file system.
>   
Even the millions of parts with their several packages each could be 
handled by a proper
directory tree. It's the connections that are the problem and a database 
expresses them
implicitly. (there is no such thing as a "symbolic half-link" that 
connects to everything
that happens to have "the other half" ;-)

As the name "gparts" suggests, the databases main objective is not to 
map symbols to
footprints but to map vendor-parts to geda-aggregats.

Independent of this post of Kai-Martin I've thought about how to express 
the relations
in the files we have now. Heavy symbols are restrictive and don't really 
do the trick.
E.g. just now, I'm in the situation to work from a breed board towards a 
series-board
and in this process may replace throughhole resistors with SMD.
It's clearly undesirable to replace the symbols in my schematic. 
Likewise it's very
tedious to replace footprint attributes in the symbols and error prone 
as of now.
And then I may not want to replace all the through-hole parts because I 
like the
via-functionaltiy of their legs or because I can put more traces beneath 
one.

What one needs is an abstract description of the pinout of a component.
This pinout can be embodied in several packages. This I think, is what the
device attribute is really for. This won't catch all cases, therefore a 
direct
connection from symbol to part should be possible.
Reading the article on transistors 
(http://www.geda.seul.org/wiki/geda:transistor_guide)
the example of "the same transistor" being available as TO and SOT package,
the concept of freezing package pins to symbol connections breaks down
completely.
- I never understood the difference of pinnumber- and pinseq attributes 
in a symbol.
As far as I can tell, the number is redundant to the seq and used for 
nothing.
It would be intelligable, if the number were used for the netlist and using
the same number for different seq's means, the physical pins denoted by seq
are electrically connected. This of course doesn't go well with the 
rendering
of symbols as of now.
Therefore, the whole business may be moved into a device-entity, that maps
the electrical connections of a part (that are represented in a symbol) to
the physical pins of its package. (I know this has been described before)

This mail is not complete, as I have to leave now.

Regards, Armin



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