[EMAIL PROTECTED] wrote: > Hi folks, <snip> > 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.
Excellent! > > - What you want the API to be able to do (requirements). > > - How you want the API to be implemented. Loadable modules? Scheme > functions? > I agree that this needs significant discussion and a design document before going off to generate a lot of code. Probably also needs some prototyped code before committing to a design. As to backward compatibility, currently my gafrc contains a (component-library "...") clause, so perhaps we allow multiple types of component library clause? Old libs are found the old way, new ones accessed through different interface. I know zero about scheme. So, I don't know if it has a built-in database interface or not. But I assume that it either has one, or can call out to external shared libraries written in <language of choice>. Perhaps something like: (component-library-helper <name of user supplied scheme function> ( <function defined parameter list> ) ) and then the user can supply a scheme function with a defined interface. We could ship an fully implemented trivial function as an example. The user supplied function could connect to a database perhaps, or simply call out to a C function. Something like: (component-library-helper sql-component-lib (host "localhost:5555" sqluser "gschem" sqlpw "g5ch3m" database "productionsymbols")) The Web 2.0 equivalent might be: (component-library-url "ftp://....") I would advocate for the data being cached locally, with a freshness test done on startup. I like to travel with my laptop and work off line. I'm sure the exact format/protocol of the library found at the target of the URL deserves a discussion of it's own. Seems to me that is extensible and backward compatible, and hopefully contains enough parenthesis. Now, what should the chooser do? The component chooser should be able to work with the attribute editor to present the user with drop down boxes populated with sensible defaults in the attribute editor. It should be possible for attributes to be automatically added and reconciled. I would like to be able to enter just the part number, and have other attributes added/updated to reflect that. For example, in my database the part number for a resistor is sufficient to specify both value and footprint, so there should be a trigger mechanism that allows the attribute editor to automatically update related attributes. Obviously, there needs to be a switch to turn this off for cases where this side effect gets in the way. Upon reflection, its clear to me that symbol definition, attribute editing, and library access are all interrelated and we want to take a holistic view from a user interface perspective. -dave _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user