>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.
maybe a Library merge and diff command would be the solution... >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. yes but that appears to be something that can be solved by disclaimer: "Content to be uploaded must be original art created by the uploader. The library server constitutes a temporary depository of user contributions." And if some party claims that their rights are violated than the elements in questions can be removed... On Fri, May 1, 2009 at 4:53 AM, Andy Eskelson <[email protected]> wrote: > 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 <[email protected]> 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 > > > > > > > > > ------------------------------------ > > 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 > > > > -- Tobias Gogolin Tel. Movistar (646) 124 32 82 Tel. Telcel (646) 160 58 99 skype: moontogo messenger: [email protected] You develop Sustainable Ranch Technology at http://tech.groups.yahoo.com/group/SURA-TECH an Open Source Electric Motor/Alternator at http://groups.yahoo.com/group/Performance_Axial_Flux and an Open Source Motor Controller at http://groups.yahoo.com/group/GoBox
