X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sun, 1 Sep 2013 09:00:17 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: [geda-user] PCB file format - compatibility suggestion
Message-ID: <alpine.DEB.2.00.1309010843540.11551@igor2priv>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Reply-To: geda-user AT delorie DOT com

Hello all,

I've started a local branch/fork/whatever of PCB to add a few features I 
need daily. These features required adding new element and pin/pad flags. 
Mainstream PCB does not understand these flags, and that is expected. 
However, loading&saving the design in mainstream PCB will remove those 
flags - which is (imo) much less expected.

The reason is not the file format, but the way PCB operates on the file: 
it tries to load and parse everything and store in a convenient native 
represetnation in memory and render the text version from that upon save.

I still remember the long threads about the PCB file format vs. xml/json; 
one of the potential reasons for such a format would be that it might be 
easier to keep unknown subtrees intact. However, I am _not_ suggesting 
changing the format.

Instead, a partial solution, a minor hack would be to upgrade the 
string<->flags converter. The flag format is a comma separated string, the 
converter could easily save any unrecognized segment as string, in a linked 
list in the flags structure. On save, the list could be appended to the 
flags string rendered the usual way. This may change the order of flags 
in a round trip but would not change the actual flag values.

Rationale: some feature patches may require changes in the file format, 
but very often this is limited to new element/pin/pad flags. Such a 
feature would allow file format compatibility among branches/forks/flavors 
of PCB.

Regards,

Tibor Palinkas