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, Nickla= s Karlsson (nicklas.karlsso= n17 AT gmail DOT com)
[via geda-user AT delorie DOT com] wr= ote:
>> 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<= /a>> 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 i= s IMHO
>> overkill.
>>
>> Lev
> I used SQL once to write a small database application but I used an SQ= L server and even though it works and could be done it will be rather compl= icated 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
=C2= =A0
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 unde= rstand your concern.=C2=A0 IMO the big trouble is SQL makes it so easy to e= xtend formats that formats quickly become extremely complicated often with = redundant and poorly thought out tables.=C2=A0 However, for someone who kno= ws 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 nea= r as potent for them. =C2=A0

=C2=A0

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 t= han YAML?=C2=A0 It's certainly more widespread but noisy and lacking re= fs, so YAML seems easier overall to me.
=C2=A0
(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 ver= y different proposition, since it doesn't get you portability to anythi= ng besides lua
=C2=A0
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.
=C2=A0
* 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")<= br> * 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?=C2=A0 It's a pain and = its already been done, in JSON, in YAML, in XML, in SQL.

=C2=A0

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 libr= aries, one small additional one is all that any of the existing solutions m= entioned above would require, not FFI=C2=A0

Britton