Re: gEDA-dev: SoC Hopeful

["C P Tarun" <tcpip-at-NOSPAMdhandanought_dot_org>]

> > Can I suggest using sqlite as one of the possible DB backends? It's nice and
> > lightweight, and it's almost an industry standard now.
>
> whatever is picked, it should probably receive some scrutiny for
> portability or in general how widely ported it is.  At first glance,
> sqlite passes a zero order sanity check (minimal dependencies, minimal
> patches in NetBSD's pkgsrc).  I tried building on solaris/sparc and it
> built.  You'd be suprised (maybe not) at how many packages need 57
> patches to build on non-(linux-i386) systems.

Does gpartman really need to have any SQL-type database at all,
necessarily? Can't this round of implementation be a proof-of-concept
implementation with a clearly defined separation between the
"business logic" and front-end communication protocols, and the
backend "storage manager"?

If this separation is done, then the PoC can be done with a flat-file
storage manager. This way, existing symbol and footprint files kept
in appropriate directories can be augmented with suitable metafiles
(e.g. index files in gdbm or Berkeley DB files) can be made to work.
As long as the API between the storage manager and the rest of
gpartman is well-documented, we can put in an RDB later. (I can
get some training projects done in our company to build alternate
storage managers, if gpartman is written in Perl, then contribute
the code under GPL).

I feel that choice of RDB at this stage is premature. And finally,
when gpartman has been proven and some of us want
industrial-strength back-ends, we may find that nothing short of
Postgres or Oracle will do for some of us. In that case, tying the
storage manager down to a specific implementation may appear
a bad idea on hindsight.

Tarun
--


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