Hi folks, There has been an interesting discussion about parts databases and the gschem component library.
What I would quite like to do is to implement something similar to what has been described, especially since I have found a major bug which only (yet another) serious component library API change will fix. I would very much like some help with the design though, because I'm actually not very well at the moment and working on gEDA is quite hard going. Also, I wouldn't like to spend weeks working on something and have people turn around and say, "No, that's not what we wanted, it was <something entirely different>!" So I'd very much like you to tell me: - What you want the interface in gschem to look like (i.e. sketches, not carefully wrought descriptions in elaborate prose). I would like engineers to be presented with the same UI no matter what the backend looks like. - What you want the API to be able to do (requirements). - How you want the API to be implemented. Loadable modules? Scheme functions? However, there are some important caveats: - All the current ways of specifying libraries must still be valid (although I imagine it would be possible to implement them _via_ a new mechanism if necessary). The old libraries must be accessible through the new mechanism in a non-crappy way. - Magic needs to be kept to a minimum, as we've too much already in libgeda. I'm not going to write a line of code until some specifications are nailed down. Likewise, I'm not going to accept patches which don't come with some sort of written explanation as to why it won't need to be rewritten in six months' time, and I encourage other maintainers not to either. My preference is for most if not all of the system to be implemented in Scheme, with libgeda presenting a straightforward API for querying the system from C programs. In fact, I would very much like to see much of what comprises the current component library system moved from C code to Scheme if possible. Finally, although this discussion probably belongs on -dev, I think it should stay here because this is where most of the existing debate on the subject has taken place. I'm here, I'm reading the mail, I'm interested. You have ideas. Let's write a spec and get it working. Peter _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user