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

[kai-martin knaak <kmk@xxxxxxxxxxxxxxx>]

Armin Faltl wrote:

> It's an independent tool like gattrib and you are free not to use it.

That's why I said "_I_'d avoid data base solutions (...)". Of course you can 
add to the list of geda applications whatever you like. Just don't expect 
everybody to cheerfully join in. 


> The idea of the tool is, to describe the relations between the entities
> you mention.

However, relations in the EDA world are not that complex. Each component 
relates to just a few footprints, not thousands. The same is true for the 
relation between real components and symbols.  


> You are also free to do searches among the thousands of little packets
> some of them with wrong lables as of now by hand.

The quality of symbols, footprints and models won't magically improve when 
stored in a database.


>> * 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.

The only way to share an entity stored in a data base is a proper pair of 
input and export functions. This means, data bases and import/export 
functions on both sides of the transfer must be synchronized or at least be 
compatible. The effort to make sure this is the case is not trivial. Ask the 
maintainer of any accounting software for what it takes to upgrade the 
system. 

Compare import/export of complex objects  with the act of giving away a set 
of files. 

I got hurt more than once and pretty badly by data base corruption while 
working with protel. Loss of several weeks worth layout/schematic design 
made me very reluctant when it comes to data bases.


>> * 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.
>>   
> ???

Think grep, find, ed, awk, perl, mv, cp, merge, diff, mkdir, ...


>> * 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,

These drivers act on one file at a time. So they are less likely to leave 
the whole lib unusable.


> esp. if one tries
> to reuse some parts of the parser. So can format converters of any kind.

A decent converter does not even Attempt to write to the original files. 


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

This is indeed a missing ingredient in the geda soup. I just doubt, that a 
data base is the best way to store the relation.


> 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.
(snip)
> 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)

Other EDA applications like eagle, orcad and protel successfully tackle this 
set of problems with the notion of "packages". The package knows about the 
symbols, footprints and models an actual component may be comprised of.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Ãffentlicher PGP-SchlÃssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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