Right, but for resistors for example, there are existing resistor symbols that will suffice for most people (once they've added their particular attributes). For ICs with uncommon pinouts, the symbol has to be created from scratch. If the database is the canonical source of part information to be fed into the design process, then the symbol should be generated from the info in the database. There shouldn't be anything controversial about pinout data -- it could easily be shared with others. The divergence in work flows starts in the conversion of pinout data to symbols; some people want hidden power pins, or parts split into several symbols, or different types of attributes, etc. This is where scripts can generate symbols to individual users' needs, or at least check that existing symbols match the known data for that part. Obviously every part has a huge number of parameters to totally specify it, and there may not be a lot of overlap between different users' part databases, but I think a database could be useful even for isolated users not sharing their data. If you do find someone else's part entry useful, you'll certainly have to add additional information to meet the requirements of your own process. Keeping the database concentrated on "just the facts" about the part should expand the usability to a very wide range of users (more than just gEDA users), which hopefully would improve the chances of finding existing entries that are useful. If we maintain a 1:1 correspondence of part number to actual physical part -- so there is only one type of package for each database entry for example -- and enter only the type of information that comes from spec sheets or suppliers (rather than, say, assigning a footprint or graphic symbol) then I think any given database entry should be generally usable for anyone interested in that part. For things like footprints or graphic symbols, those properties should be entered into the database only if they specify the tool that they're intended to work with, and if they allow for several different suggestions for that property. So for example you could have properties: gschem-suggested-symbol-1 gschem-suggested-symbol-2 pcb-suggested-footprint-1 gnucap-suggested-model-1 suggested-vendor-1 The task of actually selecting a footprint, symbol or model would be up to the individual later in their process; the suggestions would just be available to be queried if they're asked for. Also -- I think there would need to be some way of flagging errors or problems that you may find in other peoples' entries. To me, this is one big advantage of a database over files -- if someone finds an error, they could attach a note to that entry warning other potential users about the problem. *shrug* anyway, I'm not developing any of this, so these are just my thoughts on how it could work. :) mw. __________________________________________________________________
From: John Doty <j...@noqsi.com> To: gEDA user mailing list <geda-user@moria.seul.org> Sent: Thu, May 6, 2010 12:49:19 PM Subject: Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib") On May 6, 2010, at 1:34 PM, Matthew Wilkins wrote: > For less-common parts, There are so many different parts on the market, and so many different kinds of applications, design flows, prejudices, etc. that *every* part is uncommon. That's what sinks all forms of general-purpose parts database, including the ever popular proposed library of heavy symbols. John Doty Noqsi Aerospace, Ltd. [1]http://www.noqsi.com/ [2]...@noqsi.com _______________________________________________ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://www.noqsi.com/ 2. mailto:j...@noqsi.com 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user