Dave McGuire wrote: > On Dec 17, 2007, at 2:47 PM, Dave N6NZ 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. > > So do you think it's feasible?
In principal, sure. But I really don't know much about the internals of gschem, so it's hard for me to assess the difficulty of actually wiring it up. None of it is magic, though. -dave _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
