Mitch Bradley wrote: > Every entry in the master database would have a version stamp, and > versions would never be deleted, so changes or bug fixes would not cause > old designs to break.
Couldn't agree more. > It would no longer be necessary to download the entire library when > getting an updated version of KiCAD. Partial updates would be nice to have, yes. This could also be accomplished through patches or bundles of changed files, though. Even updates at the file level (rsync) would work for a while, though they get a little out of hand when you approach the 100'000 files mark. > A version control system like Subversion has some of the necessary > capabilities, Subversion imposes a layer to hide the versions you're not interested in from you. We would also have a layer that could perform this task in the form of kicad itself. E.g., each "leaf" could have an "old/" directory with obsoleted version, and kicad could automatically look for files there, and present historical data in a different form than other parts of the hierarchy. > For large CAD libraries, it's important to have a rich set of metadata > so you can find parts. One issue is also to maintain all this metadata, and the level of detail we expect to be reliably accessible. E.g., if you start including device characteristics, such as thermal characteristics, you quickly end up with fields that will sometimes be populated, and sometimes not, because the data wasn't available, because one one cared to enter it, or because the submitter didn't know what to do. A nice example for this is the Digi-Key online catalog. It's probably one of the best catalogs of this type, but it's still far too easy to miss parts, because the column you want to select on doesn't have a value. Another problem with a fixed attribute structure is that there are more and more multi-purpose parts that dont' quite fit in the "generic" model. E.g., think of battery charger chips. The question is also whether we really want to have a catalog that's good for component selection, or whether it's sufficient to have a catalog that allows us to look up symbols and footprints for components we've already selected. In some cases, these items would be specific to individual products, e.g., MCUs, while in other cases, one symbol could cover an extremely broad class of items, e.g., "resistor" or "diode". Another issue is that component selection is often based on non-technical critera, such as price and availability. So the most likely location to place the first query would be the local shop, not some compendium of all technology known to mankind. > The problem with rigidly structured hierarchies > is that there are several plausible ways to organize them. Yes, that's the crucial problem. A well-designed initial structure should help against ambiguous hierarchies. E.g., if I'm looking for a Schottky diode in a SOT-323 package, I would find it in a hierarchy that puts it under discrete/diode/schottky/sot-323/ as well as in a hierarchy that puts it under smt/sot/323/diode/schottky/ but I'd be confused if the hierarchy had top-level categories "discrete" _and_ "smt". So, in my opinion, the main question would be: can we come up with a hierarchy where everything has a place where it can be found, given reasonable knowledge of the item ? If not, we can forget about using a hierarchy. If yes, I think a hierarchy would offer an efficient structure for putting things, efficient both for the CAD system and for the user. > Each part could have a list of > attributes, and you could search on any combination of them. Well, I'd certainly like to have a full-text search in addition to the rest. That also allows for the occasional oddball device that defies all other categorization. There are, of course, the usual issues with choosing keywords, etc. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net/____________________________________________/ ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/W4wwlB/TM --------------------------------------------------------------------~-> Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please contribute your symbols/modules to the library folder in the group files section. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-devel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/kicad-users/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
