Looking back througth this thread I think there is a lot of common ground, but it is abit of an ad-hoc discussion and I am perhaps the biggest culprit here.
Marcus's post was perhaps correct in listing the requirements, but before we go forward we should perhaps define the minimum steps required on the part of KiCAD, until we know what way that will be going it would be stupid to build on arbitary definitions. Let's state that we need: 1) An unqualified and unlimited list of name/value pairs that can be associated with a component and that this listed will eventually be available as a data grid in the properties list rather than a list of 8 fields. 2) It should be possible to define the fields at a library level such that default values are allready set when you use a component. 3) The library editor should be able to browse for components on the internet and allow us to use the compnent straight from the library (perhaps updating a local cache) or to review/edit the component and drop it into our personal library. 4) The components should be presented on the internet in a standard read only fashion. It is up to individual users to update thier libraries or for groups of users who maintain standard libraries to publish new releases of thier collections. 5) PCB footprints and editor works in a similar fashion, and adds the possibility to associate 3D views which may also have been fished from the internet. At this point it would perhaps be the case to approach KiCAD developers with our proposals. I feel a bit cheeky as someone who only started using KiCAD yesterday and yet am allready making "demands" on the developers who have so kindly made this package available. On the other hand we are esperienced professional EDA users who know how EDA tools get used in the big wide world, I feel our feedback is important to the developers. BTW, I am not even sure **how** we should approach the developers. Are any reading this post? These requirements do not AFAIK actually require any changes to core KiCAD file formats and functionality, just extensions to the component editors, they could probably even be developed seperately using the KiCAD classes to visualise and edit the components in order to ensure future compatibility. The big issue is the protocol used to present the libraries on the internet such that they may be browsed and accessed programatically by the editors. CVS is one possibility, but it requires that either someone maintains a centralised multi-project CVS servers (who?) or that individual groups or users who want to share libraries must set up thier own server, which could be a problem for many, who perhaps just won't bother. The alternative is the idea of presenting the files in a standard ASCII format via HTTP, such that they may be published on any website, including free homepages, and with the Wiki being used an index were users manually select sites to put into the library editors browsing list. In this case it would be up to individual groups to decide how they would cope with version management. This makes it is for individual users to publish thier work, whilst people wanting to form groups to maintain a centralized library will have a bit more work involved. But that seems the right way round to me! BTW, of course it may well be that the developers have allready approached the problem of library distribution and maintenance and have thier own solutions in the works. Once again, I think it is important that these issues are clarified before we go into details. We started off by saying "let's define those fields", but clearly 8 fixed fields just ain't enougth, and having good library support is going to be an important issue for the future of KiCAD.
