A few thoughts about this...
You do NOT want a database anywhere near Kicad. Fair enough if you want to create a database that REFERENCES parts and modules, but such a system should play no part in the operation of Kicad. I have seen far too many situations where over engineered systems fail, particularly during upgrade operations, where database links get broken and it's almost impossible to get them working again. Kicad is used by many different types of people of different abilities, and if there is one thing that I have come to appreciate over the years, is that the KISS principle of operation is much safer. A separate system that helps manage things is fine, something that Kicad becomes DEPENDANT on is not. The ability to manage libs and modules is already built into Kicad. Both parts and modules can be imported and exported individually. Also entire libs can be added. So it really comes down to a choice, the used can either select an entire library to be downloaded or get the individual libs and modules. I would agree that the method of adding libs and modules and various parts within them could do with some improvement, to make the process a little easier, that would be nice, but that's a fairly minor requirement. The biggest problem at the moment is when you download a lib, say during an upgrade, this overwrites any parts that you may have added to that lib. Once you learn to keep parts that you have added in a different lib then the problem goes away, but it's still a problem. It would be better in terms of part management to have a method that allowed a lib or mod to be updated without overwriting additions and modifications. With any system that shares things, there is a very important area that MUST be managed CAREFULLY. That is the issue of copyright. Without getting into all the possible issues, lets me just say that you must be VERY VERY careful as to the source of any part shared in such a system. As one crude example, just think if some kind soul converted the parts and modules from another PCB design package and then decided to share them. Even collections of parts and modules published for use by manufacturers have a copyright to them. Just be careful on this aspect. Another issue that comes to mind, is what I would call the "fittness for purpose" A part and module that I design, while perfectly suitable for my needs may well not be suitable for someone else. How can any particular part or module be certified and for what use? Andy On Fri, 1 May 2009 09:57:30 +0200 Lothar Behrens <lothar.behr...@lollisoft.de> wrote: > > Am 30.04.2009 um 21:32 schrieb Tobias Gogolin: > > > > > > > >"Wishing" for a component I think is NOT the best solution. Just a > > mechanism > > >for "Sharing" components would be good. So if I have a Library of > > components > > >I want to share then I just click "Share" and that goes to the > > repository. > > >If I would then want to search for a components I would search > > (from KiCad) > > >in that repository. > > > > > What I mean with 'wishing' components is more like 'how many like to > have that component' > to see which components one could create / publish. It is not meant > barely, who makes me this > component. This explicit wish is usually a paid service I think. > > So just get a glue, which components are required the most. And then > even funded component creation could be done easy. > > I agree and congratulate on the uptake of these efforts! > > I also wonder how these remote components, (schematic symbols, > > padstacks, and 3D models) could be integrated with what is currently > > managed as Packages (I would almost prefer something like directory > > structures (user manageable) similar to Jar files)? > > There may be an interface for the plugin: a virtual library package > > remoteLibrary.xyz ? > > > > > Aren't there cases that I search for a specific part with a specific > housing - eg. DIL40 or PLCC44? > > If all the components are packaged into some 'library's, the network > traffic would be very high :-) > > What about an interface that pulls a specific componet + the required > package out of the 'web service' > and delivers it as TGZ or what ever? > > I have created a small PDF file about my thinking of a database > centric solution. The end product that will > be carried around would be any format, because it could be packaged > dynamically. > > Here is the file I uploaded: > http://groups.yahoo.com/group/kicad-users/files/KICADDBLibMan.pdf > > With a database you could do much more things, eg. add vendor > information, reseller information and even prices. > When the database is at a public place, we will get very fast an > overview, where we could get the cheapest parts for our BOM. > (Simply issue an SQL query and enrich the BOM) > > I hope my ideas are not too crazy :-) > > Lothar > > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de > Lothar Behrens > Heinrich-Scheufelen-Platz 2 > 73252 Lenningen > > > > > > > > > > > ------------------------------------ > > 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 visit http://www.kicadlib.org for details of how to contribute your > symbols/modules to the kicad library. > For building Kicad from source and other development questions visit the > kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups > Links > > >
