X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: geda
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] A fileformat library
In-reply-to: <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w@mail.gmail.com>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <CAJXU7q_qxdvJaejF-VcY=u7VHZ-zrfrc+Z7-qSwfFyPdy-umxw AT mail DOT gmail DOT com> <B02363CD-469D-493A-AC15-1D5DC7836982 AT noqsi DOT com> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <CAM2RGhTficnys3a4xs=UBFvk8aPwpzYWUADFLP_pUQ+R1iKs0g AT mail DOT gmail DOT com> <0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com> <CAC4O8c_UAiFE-vGfoE2tXppHLhaa0dSYz9o_rkdCBo7_SRRtxw AT mail DOT gmail DOT com> <FFBE7623-E240-4798-96B0-2BECF56C8E29 AT noqsi DOT com> <CAC4O8c980g1gj15=5njstC_BT-WYDgKQx9BRycdFKA8OvgtiOg AT mail DOT gmail DOT com> <B54C0E1F-1986-4C79-9F70-7F1919B8B26D AT noqsi DOT com> <CAC4O8c9bxJP1eMG4yz3YwKkQJRmsDGmLQ0aMd5pJRyu0WpdCtQ AT mail DOT gmail DOT com> <C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com> <CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt> <D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com> <CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com> <CAC4O8c8zk8=Py1yX6fVqF+35SYe39Li=y4jZ8bCeZ
 1Ev8WccAg AT mail DOT gmail DOT com> <20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se> <CAC4O8c8cVr1H3skmbGo4Rhf5ZTZj8bDxJw8a9C4qfHeGyXZ4XA AT mail DOT gmail DOT com> <20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se> <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w AT mail DOT gmail DOT com>
Comments: In-reply-to "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
   message dated "Wed, 06 Jan 2016 10:58:49 +0100."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20160106133049.5A0E9809D79B@turkos.aspodata.se>
Date: Wed,  6 Jan 2016 14:30:49 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Levente:
...
> When selecting a file format I would not have such constraints like "it
> should be pretty for a human eye". CAD data is so complex, that one can
> (and I believe should not) parse them with naked eye. For a computer,
> binary is much more efficient.

If we really are going the "complex cad data" route, I'd head Peter 
Cliftons advice to use step. And if I'd start programming with that I
wouldn't concider the price of the step-cd be of any consern.

> So I still prefer the SQLite database, as that library is optimized for our
> purpose. Yes, I prefer to have a library, that parses our files, and gives
> us the possibility to use, or modify the data. I prefer this way because we
> have approx. 50 different implementation of pcb/gschem file parser. There
> is one in pcb/gaf, and all the other power users wrote their own. It would
> be much better to write the parser once, and other could use that. If file
> format changes, you have to just change one code, and not 50+.

I agree that it would be wery nice to have a lib for sch/pcb file
(regardless whatever format they have) parsing+extra with bindings to
mult. languages. But as you said we already have one (+49 others),
I don't which one is the best one, do you know ?
Can we take that one and improve upon ?

> If we use a standard file format (SQL, YAML, JSON), the parsing library
> could be very thin. The independent parsing code is already written. Only
> the application (gEDA) specific code has to be written. Remember, all of us
> has very limited time to contribute code to gEDA nowadays.

So your stance in the end, is that it is the doers who decide,
irrelevant if the lib is thin or thick ?

And the first step would nevertheless be to be able to parse the 
current formats, at least for backward compatibility.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57