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