--- In [email protected], Werner Almesberger <[EMAIL PROTECTED]> wrote: > > Mitch Bradley wrote: > > Hierarchies work well only in very rare cases where the appropriate > > structure for the hierarchy is blindingly obvious to everyone. > > I fully agree with Mitch, not only because phylosophical reasons, but even because the database idea is easier to implement. The Unix file system structure is fascinating, but only few people should really bother about that - exactly the same as my car: it could interest me about the technical concerns, but all I want is to turn the key and go where I want.
So, I resume things. When I draw a schematic, I'm interested in finding the correct symbols to put in it. If I have two kinds of resistors (two shapes: boxed and -/\/\/\/\- (sorry, don't know how to explain in English)) I am happy. The same applies to anything: when I think about a 7805, one of them is enough. I don't worry about package, or thermal characteristics: if I do, I should already know that the component is available with the requested features. As long as the component in the library has the correct pins, it's good for me. The second step is to assign a package to every component in the schematic. Again, there are not thousands and thousands of different packages or, at least, they are not commonly used. If I really need some strange package, then I can draw it. Werner suggests that a lot of informations should be supplied with components, like links to datasheets and so on. I don't see this the same way. People get annoyed by filling long forms - the schematic shape and the PCB footprint is all people is really interested in. This said, let's talk about implementation. A centralized internet database should contain records for every component and every package (two databases). A record contains no more and no less than the data at currently present in a module file or a library section, with the same format. These databases are mantained by a number of trusted maintainers, some volunteers around; their work will be hard at first, but will decrease in time. I think this is painful, but necessary - we cannot let the databases grow wildly. (Note to Ian Bell: the more we wait to centralize the database, the more work will be to be done; if we believe in KiCAD we should bet on this and win our bet). This database is quite simple to implement; as already noted, many sites offer MySql for free. KiCAD would be distribuited with a "standard" small library, just like now. Then, every user mantains its own library or its own libraries, updating them from the internet. The Component Editor and Module editor will change slightly, offering a new function for accessing a online database. A search by keywords returns a page (limited in number of results); the user marks what he/she is interested in, and the data is downloaded and stored in the special local library "internet". From there on, a user can move the downloaded components/packages everywhere. KiCAD should not include some sort of database. The Mitch's idea of keeping every record of every version is appealing, but risky and perhaps not needed. The risk is that a search for "74xx373" yelds some 100 results nearly identical. Not needed because when I download a 74HCT373 I keep my local copy (and EESchema keeps a cache of components). If I want to update my 74HCT373 I should know what I am doing. Three things are needed to implement this system: - developers of KiCAD should implement the remote query/download/store of data - a stable site for storing the database should be found - volunteers must be found to maintain the databases. Cheers to all. Let's discuss more to ------------------------ 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/
