[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Parts DB API



Hi folks,

There has been an interesting discussion about parts databases and the
gschem component library.

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.

I would very much like some help with the design though, because I'm
actually not very well at the moment and working on gEDA is quite hard
going.  Also, I wouldn't like to spend weeks working on something and have
people turn around and say, "No, that's not what we wanted, it was
<something entirely different>!"  So I'd very much like you to tell me:

- What you want the interface in gschem to look like (i.e. sketches, not
carefully wrought descriptions in elaborate prose).  I would like
engineers to be presented with the same UI no matter what the backend
looks like.

- What you want the API to be able to do (requirements).

- How you want the API to be implemented.  Loadable modules?  Scheme
functions?

However, there are some important caveats:

- All the current ways of specifying libraries must still be valid
(although I imagine it would be possible to implement them _via_ a new
mechanism if necessary).  The old libraries must be accessible through the
new mechanism in a non-crappy way.

- Magic needs to be kept to a minimum, as we've too much already in libgeda.

I'm not going to write a line of code until some specifications are nailed
down.  Likewise, I'm not going to accept patches which don't come with
some sort of written explanation as to why it won't need to be rewritten
in six months' time, and I encourage other maintainers not to either.

My preference is for most if not all of the system to be implemented in
Scheme, with libgeda presenting a straightforward API for querying the
system from C programs.  In fact, I would very much like to see much of
what comprises the current component library system moved from C code to
Scheme if possible.

Finally, although this discussion probably belongs on -dev, I think it
should stay here because this is where most of the existing debate on the
subject has taken place.

I'm here, I'm reading the mail, I'm interested.  You have ideas.  Let's
write a spec and get it working.

                                    Peter




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user