Dave McGuire <[EMAIL PROTECTED]> wrote: > On Dec 18, 2007, at 12:31 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. > > I'm also unfamiliar with gschem's internals. I wish I had more > time; I'd love to code this up. I'd love to be able to, say, point > to your parts database server, point to DJs, point to Dan's, etc., > and have stuff from everyone's libraries instantly accessible via the > Internet. Such a database could be extended to include such things
That is a very good idea. We must have well defined interfaces for this! > as SPICE/gnucap models, footprints for PCB, PDF datasheets, suggested > vendors, "as seen" pricing and availability information, etc etc. > > WOWWOW that'd be powerful. I'm drooling, here. > > -Dave > -- Levente http://web.interware.hu/lekovacs _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
