On Wed, Jan 6, 2016 at 9:47 PM, Sabin Iacob (iacobs AT m0n5t3r DOT info) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

On 01/06/2016 09:28 PM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com)
[via geda-user AT delorie DOT com] wrote:
>> On Wed, 6 Jan 2016 18:09:12 +0100
>> "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via
>> geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
>>
>>> Then it come to SQL can you solve file open and save as usual? Or do
>>> you have to make connection to some kind of database?
>> Yes. SQLite.
>>
>> https://www.sqlite.org/
>>
>> Using server/client architectured database engin like postgresql is IMHO
>> overkill.
>>
>> Lev
> I used SQL once to write a small database application but I used an SQL server and even though it works and could be done it will be rather complicated for ordinary use. With a simple library binding it could be worth a try.
>
>

all right, can't stand it any more, I've been eating my words for a
while now: please, please, please, stop with this SQL nonsense... I know
that once you find a new shiny hammer everything looks like a nail, but
schematics and PCBs are graphs at the core, and SQL databases are a

PCBs are not graphs

pretty bad fit for storing graphs (yes, you can shoehorn them in - see
mptt - but the results are more often than not awful); I too would like
to see a more comprehensible file format for PCB, but SQL will be
anything but comprehensible (source: used SQL extensively for the last
15 or so years as a developer and a server babysitter).

I've worked with it quite a bit too, I understand your concern. IMO the big trouble is SQL makes it so easy to extend formats that formats quickly become extremely complicated often with redundant and poorly thought out tables. However, for someone who knows SQL it's tough to look at them and say that vivified objects from a format like JSON (array+dict) or YAML (array+dict+ref) will be anywhere near as potent for them.

as far as file formats go, while something standard like json or
(cringe) yaml or (cringe even harder) xml would have advantages

Out of curiosity you like JSON better than YAML? It's certainly more widespread but noisy and lacking refs, so YAML seems easier overall to me.

(ubiquitous library support, easy-ish to parse and modify with awk &
friends for people who are so inclined), it will degenerate into
unproductive holy wars (see previous pushes for lua as the file format,

lua as the file format is a very different proposition, since it doesn't get you portability to anything besides lua

or various bickering about which text format is best); the way I see it,
the process looks like this:

* decide on data model; this is where you think hard about what you need
to do, how it maps to the physical world, etc.

Yes, this is the hardest part.

* decide on syntax, write formal grammar; this is where you take into
account parse-ability with standard text tools and human brains (I, for
one, am a big fan of "design for humans first, computers later")
* have a parser generator generate parsers for every language you use,
generate some more as they are requested

What do you get by doing these two? It's a pain and its already been done, in JSON, in YAML, in XML, in SQL.

problem solved, you get canonical parsers for all languages that are
needed and no extra layers of FFI (which can be needlessly heavy)

gEDA already uses a big stack of libraries, one small additional one is all that any of the existing solutions mentioned above would require, not FFI

Britton