Re: gEDA-user: Parts DB API

[Dave N6NZ <n6nz@xxxxxxxx>]

peter@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user