Re: gEDA-user: Fwd: Parts DB API: the story so far

[Stuart Brorson <sdb@xxxxxxxxxx>]

> I think you two are arguing different things.
>
> Stuart claims that REQUIRING a database ENGINE for ANY use of gEDA is
> bad for the project.
>
> Steve claims that ALLOWING a database SCHEMA for MANY uses of gEDA is
> good for the project.
>
> I think you can both be happy with a gEDA that MAY use a database
> engine, but does not NEED one.  Likewise, gEDA may ship with a
> "database" which is merely a collection of CSV text files - complex
> enough for simple uses yet without the dependency hell of requiring a
> relational database engine.

I think we're having a violent agreement.

Yes, allowing power uses to plug-in a database is a good thing.
Mandating that everybody use a database is bad.   I believe Steve and
I can eventually agree on this.

I see several layers when peeling this onion.  Here's a vision with
several stinky layers:

1.  The basic gEDA installation should work without any changes to the
existing symbol/footprint operation.  Basic gEDA is for newbies,
students, and folks with minimal project requirements.  It should work
out of the box, as it (sometimes) does now.

2.  Providing hooks for symbol/pin/footprint mapping is fine, as long
as the system functions in the current way in the absence of mapping
files/databases/etc.  The hooks can take any form; the hooks will be
some sort of API which calls methods on an external module (i.e. a
plug-in).

3.  A rudimentary mapping file -- a flat text file -- is OK, and could
certainaly be shipped with the base gEDA.  The mapping would be
performed using an *external* plug-in module, also distributed with
gEDA.  However, I wouldn't personally like to see the mapping module
activated by default, since:

   1) It represents a level of indirection over the the existing symbol
      scheme.  This can be confusing to newbies.
   2) It is an additional component which can break.  Less components =
      greater reliability.

IMO, The user should be required to plug in the module himself, so he
knows what has happened.  The mapping file could be enabled using a
setting in gafrc, or perhaps also using a button in the gschem/gattrib
GUI.  Finally, the mapping module could easily be a component of
xgsch2pcb.

4.  For advanced users, the external plug-in which does
symbol/pin/footprint mapping could be replaced using a different
plug-in talking to a database.  This database plug-in could implement
any and all functionality which power users might bake into it.   I
could certainly support distributing the database plug-in with gEDA,
but would not want to see us get into the business of distributing or
supporting databases.  Therefore, our database module might be a
plug-in which emits SQL over a socket (or DBUS, or whatever).  In any
case, there would be an adaptation layer between gschem/gattrib and
the database; that adaptation layer would be a plug-in.

Sound sensible?

Stuart


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