Dave McGuire wrote: > Perhaps what is needed here is the concept of > "data sources", with a defined API that forms an abstraction layer > between gschem and the component database(s), whatever format/database > type/etc they may be stored in. That way, "data source modules" (MySQL, > Postgres, Oracle, flat files, whatever) could be implemented, even as > dynamically loadable modules, and instantiated by config file statements. > > As this'd be a layer of abstraction between gschem and the actual > component data, it would (and should) be transparent to the user, who > would simply be presented with the standard component chooser dialog > which would serve to "unify" the data.
You're right, of course. -dave _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
