On Sun, May 2, 2010 at 8:29 AM, John Doty <[1]...@noqsi.com> wrote:
>> * 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.
By this reasoning, gparts should work with the project symbol files.
We are already using this file spec, and it has already proven its
value, comprehensibility, and flexibility over and over.
The problem here is that few seem to recognize that it is perfectly
sensible to see a .sym file as a container for a relation.
Databases may be evil, but you have to admit this diagram:
[2]http://www.geda.seul.org/wiki/geda:gparts_dd#part_database
is a much more coherent start to understand the situation that gEDA is
trying to model than all the footprint/device fun. From a new user's
perspective.
[snip]
> 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.
I will guess you let the defaults in gEDA take you down the usual
low-productivity path:
1. You used a library resistor symbol by reference rather than
making a project copy.
2. Then, of necessity, you attached footprint= attributes to each
instance instead of your resistor symbol instead of placing a
footprint= symbol in your project symbol.
Your situation is very familiar to me, and is precisely why I use
the project symbol collection approach for any large gEDA project.
I use a probably almost identical project symbol approach. If this is
high-productivity way I'd hate to see the alternative. Essentially,
everybody gets to continually reinvent the same heavy symbols. Its got
to be possible to do better than this.
> 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)
Except that can already be described by the symbol file, so why have
a redundant way to do this?
I'm not sure what the correct approach is here. These days, too many
users seem to want separate, labelled things like "databases",
rather than seeing all the isomorphisms that make life in the
technical world simpler, better connected, and easier to comprehend.
Well, all the parts vendors keep things in databases. I agree that the
server databases manage to be such a
pain in the ass to install and administer that they usually are not
worthwhile (including in this case). I *like*
the files way as well, don't think I'm just a db junkie :) But really
this is the sort of thing DBs are really good
for.
What about SQLite? I've *glanced* at its home page a couple times in
the past (really no more than that),
and in really less than 10 minute just now I was able to download it,
build it, create a database in a file,
query it, and dump its generative code (probably a good format for
grep-happy people like you :).
What I've been thinking of lately is a sort of heavy symbol wiki that
people could add to as they create their
own project parts like you do. You could build parts in chroots with a
few things (Pcb_9.pm tragesym etc.) available. I'm not sure how useful
a DB would be in an application like this but I wouldn't rule it out
just based
on bad experiences with servers databases.
Britton
References
1. mailto:j...@noqsi.com
2. http://www.geda.seul.org/wiki/geda:gparts_dd#part_database
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
