X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.98.4 at av02.lsn.net
Subject: Re: [geda-user] A fileformat library
To: geda-user AT delorie DOT com
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1512230552520 DOT 9035 AT igor2priv>
 <FC796A30-DF21-42E0-89D4-48F3C202BCAE AT noqsi DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1512230648180 DOT 9035 AT igor2priv>
 <A6BF931F-181E-4B69-8B3E-E1BD202DE7C5 AT noqsi DOT com>
 <20151223194905 DOT 7676 DOT qmail AT stuge DOT se>
 <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0 AT noqsi DOT com>
 <201512240626 DOT tBO6QuW0031998 AT envy DOT delorie DOT com>
 <s6negecytg1 DOT fsf AT blaulicht DOT dmz DOT brux>
 <CAJXU7q-La9qBqbt-x8G6LnWpxaQSYiVwngVLG9ScUFzzd1TWGg AT mail DOT gmail DOT com>
 <20151224124303 DOT GA22838 AT cuci DOT nl> <20151224142825 DOT 23916 DOT qmail AT stuge DOT se>
From: John Griessen <john AT ecosensory DOT com>
Message-ID: <567EE79F.7080603@ecosensory.com>
Date: Sat, 26 Dec 2015 13:16:47 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151224142825.23916.qmail@stuge.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id tBQJGrW0000754
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

On 12/24/2015 08:28 AM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote:
> Stephen R. van den Berg (srb AT cuci DOT nl) [viageda-user AT delorie DOT com] wrote:
>> >When you then extend the structure in SQL which the exporter/importer
>> >don't understand, you either live with the fact that you lose
>> >information when you export/import it, or you extend the
>> >exporter/importer as well to support the new structures.
> Or stay with the status quo, which I don't think is good enough.
>8

I want to be able to sift the data.  Now there is a way with scheme/LISP similar to Skill code
I used to do, but having SQL could be very good also -- there could even be generic GUIs for it.


On 12/24/2015 09:18 AM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote:
 > John Doty wrote:
 >> >I want to liberate users, not control them.
 > The argument doesn't hold because users must learn the .sch format
 > in order to work with it by hand. This remains true for any format.
 >
 > One important point is that reusing any existing representation makes
 > it more likely for users to already be familiar with that format or
 > language, as opposed to the 0 probability for gEDA-proprietary (open)
 > formats.
What effort level is it going to be to keep using a .sch file as well as SQL
and keep them in sync?  By sync'd I mean every read of .sch updates the SQL,
and every change to SQL writes to the .sch file.

On 12/24/2015 04:58 PM, John Doty wrote:
 > Except that records delimited by newlines containing fields delimited by whitespace is a far more common and transparent 
convention than others.

I have to agree with that feeling.

On 12/25/2015 03:13 PM, John Doty wrote:
 > I’m not talking about pcb. I’m talking about geda-gaf. Geda-gaf is a much cleaner design. The pcb format doesn’t even represent a
 > proper model of what a printed circuit board is.

Not talking about PCB doesn't solve many wants for very many people, so I want to talk about PCB, but yeah, its data model is 
spaghetti, and needs rework.