--- In [email protected], "roger_irwin" <[EMAIL PROTECTED]> wrote:
> The problem is a) in the guidelines and b) in the use. > > There are 2 ways at looking at how libraries should be: > > *************** > > Mode A) > > Libraries should be standard and centralized such that we can link > designs to components in libraries and accept the component form as it is. > > **************** > > Mode B) > > Libraries should be bazzar where you fish around for components to > place into the private library which holds all the components of your > design. > > ********************* I agree with Roger regarding mode A and mode B use of libraries. I'm not an electronics engineer myself, but I have come to understand that building and maintaining a library, for personal use or in an organization is a big issue. My impression though is that the size of the issue is strongly dependent on the ease of use of the library management tools. I guess part of this reasoning is consistent with the fact that so many users on this group request library conversion tools from other EDA suites. Could it also be so that providing a good component library with an EDA tool is an important sales proposition for the commercial tools? > Am I a genius? I think so, but I bet the next post is going to point > out a wapping big hole in my reasoning :-))) No, I see no holes in your reasoning! I just want to stress that ease of use is going to be the most important success factor for being able to provide a competitive library with Kicad. I think most of us envision the Kicad component library as a collaborative library which is ever growing, and evolving, and which facilitates several schematic symbol styles, pad layout guidelines, etc. I agree that Kicad needs an Internet enabled library editor/browser/manager, were users can browse trusted (or experimental) component library feeds, easily copy components to their own private libraries if they are mode B users, and publish their own work. One problem (which may have a solution already) is coping with the fact that once libraries are distributed across the Internet and start evolving, components will be added, removed and modified inside existing libraries at an increased rate. With revision control (subversion, CVS, etc) this can be dealt with by locking a project to a specific revision of each library used, but that could also make a cumbersome situation if a new component which is useful in that project shows up in a newer version of a library. Mode B users will not suffer from this since they hold private copies from any version of any library. In fact I cannot come up with a single solution for mode A users that does not happen to be the equivalent of becoming a mode B user. My imagination sets the limit here. Perhaps someone else on the group is more imaginative than I? :-) Additional requirements for a library editor/browser/manager for Kicad: * Internet enabled (e.g. enter library pathnames as URL:s) - Libraries imported from the Internet read-only * Support for publishing libraries on the Internet - Must have: Single user publishing on a single URL - Nice to have: Multiple users publishing on a single URL * Built in revision control - Revision optionally included in library URL:s for browsable libraries - Revision control for published libraries - Nice to have: merge revisions (when more than one user publishing on an URL) * Copy components (symbols, footprints and 3D) between libraries - Nice to have: Keep track of copy source * Nice to have: Announcements of new versions of used libraries * Nice to have: Links! Option to link to a component in another library rather than copying it. - Optional link de-referencing for published libraries I think that just about captures what is needed from a user's point of view. The back-end implementation could be e.g. a Subversion repository (one or several), but that is secondary to defining a good set of functionality. Comment about links: I think links could be a powerful feature, but one should beware! Powerful features share a common property that they are easily used inappropriately. What I had in mind was to be able to maintain a published library which contains links to current versions of private libraries. A user may then maintain a set of private libraries and automatically publish current versions of selected parts from several private libraries with a single click. Nice to have, but we might well do without! Regards, Erik Sundkvist
