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

[Stuart Brorson <sdb@xxxxxxxxxx>]

I'll respond once and then go back to lurking.  Anyway I don't have
anything more useful to say about this!  :-)

On Thu, 20 Dec 2007, Steve Meier wrote:

> Wow, I am in the 1%.

Yup.  Since you re-wrote libgeda to support features you needed, you
are definately in the 1%, perhaps in the 0.1%!

The point is, the remaining 99% can barely make gEDA work as it exists
right now.  The will be completely flummoxed if they need to take
components out of a database, much less build a database.

> Fair enough, when geda couldn't provide capabilities for hierarchical
> buses I went out and implemented my own version down to rewritting hudge
> chunks of libgeda (I am calling my derivative/fork libakeda since Ales
> was concerend about confussion). I also have a second project that I
> have been working on which is based upon the mr1 erp suite (I have
> included inventory management among other features).

Yup.  You should consider commercializing it if it works out.  I'd
personally like to see a little cottage industry grow up around gEDA.
Advanced features like gEDA integration with an ERP system are
candidates for a real business venture.

Also, once the database integration is underway, then a business could
sell complete, vetted sets of symbols/footprints/BOM entries.  I'm
suprised somebody hasn't done that already...  ;-)

> My recent efforts in libakeda to switch the reading and writting of sch
> and sym files from c code to scheme scripts is to allow supporting of
> geda even as I (as I expect) deviate my file structures further from the
> stock geda.
>
> My own personal experience is that it is far far far easier to write an
> sql query then it is to create data structures, input methods and search
> routines from scratch.

*Chuckle*  You also rewrote libgeda "to switch the reading and
writting of sch and sym files from c code to scheme scripts..."  I'd
be pretty confident that you occasionally dream in SQL.  However, our
target user is a college student who wants to design a robot control
board for his class (or as a hobby).  They should not be required to
deal with a database just to crank out a simple two layer
microcontroller board.

That's not to say that gEDA shouldn't be capable of advanced usage.
Indeed, it should!  But the entry point should be low, and the suite
should *scale*.  That is, the base gEDA install should be simple but
useful -- a schematic editor, a netlister, a layout editor, and some
related utilities.  Also, a project manager tying everything together,
but able to  function without the advanced components.  Then, if you
need to grow, and you want to use a database for choosing components,
great!   There should be a different tool to allow this, and it should
hook into the existing tools.   But you shouldn't need a database to
just create a simple schematic.

>> From a rational stand point DJ's and Stuart's Idea of a plug in support
> of rdbs is probably a good idea.

Indeed.  Provide the hooks for database integration.  Perhaps write
a separate database utility (or be able to hook to it via scheme or
IPC or DBUS), but don't make it part of the base gEDA install.  GEDA
should start simple, but allow for scaling up if desired.

Cheers,

Stuart


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