DJ Delorie wrote: >> These would be data structures that can contain all information >> relevant to an entity us humans like to build electronics from. > > I don't think this conflicts with any of the other ideas we've > proposed.
I don't think so, too. :-) But a database of packets might look different from a database that does the assignment of footprints, data sheets and meta data by some other means. > It's almost like each component would be a micro-library of > its own. In a sense, yes. The scope of this micro-lib up to the designer. Extremes, I can think of are: A packet for a specific microprocessor. * a model name * main symbol * a power supply symbol * a footprint * a link to the data sheet * acquisition information * and a bunch of notes. This is like a container with different kinds of objects. A packet for NPN transistors. * alternative symbols (with circle, without, different arrows...) * alternative models (BC..., 2N... ) * alternative footprints (TO92, TO220, TO347, SO23, SOT223, pads optimized for hand soldering, optimized for reflow, ...) This is like a little library with different objects of the same kind. > Likewise, PCB has footprint variants you should be able to switch > between during layout, like RESC1608{M,N,L}. The back-annotation problem remains. Is there any sensible way to do back-annotation with a hierarchy where a subsheet is used multiple times? >> In schematics and in layouts it may be referred to with a unique name, > > Hmmm... we need a way to scope names, I think. true. Maybe require that packet names are unique within a library. They could then be referred to with libname/packetname. If only the packet name is given, then there may be a list of libraries to search from. > Maybe come up with an > URL structure for specifying library/component/symbol/script/whatnot This seems complicated. Who would specify this URL? If it is the user in a file chooser like dialog, then this means five point'n clicks. Or do the / mean alternatives? Then it is more like a search pattern. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user